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1 USER-DEFINED DYNAMIC COLLABORATIVE ENVIRONMENTS 

2 This application is related in subject matter to and claims priority from provisional U.S. 

3 application serial number 60/101,431, filed on September 22, 1998. The contents of that 

4 application are bodily incorporated herein. 

5 BACKGROUND OF THE INVENTION 

6 1. Technical Field 

7 This invention relates generally to computer systems and networks. More particularly, 

8 the invention relates to systems and methods for providing user-defined collaborative 

9 environments for transacting business or electronic commerce. 

10 2. Related Information 

11 Following hurricane Andrew, many insurance companies sought to limit their risk by 



12 withdrawing coverage from coastal areas. While this made good sense for the specific 

13 companies, it was not acceptable from a societal perspective. The cities, towns, homes and 

14 businesses built near the coasts could not afford to go without insurance, nor could the financial 

15 institutions that loaned money on these properties afford the risk. The problem facing the 

16 insurance companies was not the absolute magnitude of the risk, but the concentration of the 

17 risks in one area, leading to the possibility of very large losses resulting from a single event. 

18 One law firm had conceived the idea of providing a mechanism for insurance companies 

19 to exchange risk. Companies with a high exposure in one area (e.g. Florida windstorms) could 

20 reduce their risk by ceding part of this to another company with non-coincident risk (e.g. 

21 California earthquakes) and assume part of the second company's risk in return. A company 

22 (CATEX) was formed to conduct such trading, but the trading rules had yet to be defined and the 

23 trading infrastructure had not yet been developed. CATEX postulated that the key barrier to 

24 insurance risk trading was determining the relative risk of different perils in different regions. 

25 One approach suggested by CATEX was to try to estimate these relative risks (termed 

26 relativities) for a broad set of perils and regions, to provide an initial basis for trading. 

27 It was recognized, for various reasons, that this could not be done feasibly because: 

28 general estimates of risk, rather than the risk for specific locations, buildings, ships, etc. would be 

29 inadequate for commerce; there were many risks to evaluate given all of the permutations of 
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1 location, perils, and structure; and companies would not be willing to trade risk based strictly on 

2 a third-party's analysis 

3 An analysis of the problem, however, indicated that estimating the relativities was not 

4 essential to facilitate trading, or, in a broader sense, that trading was the only way to address the 

5 problem of insuring concentrated risk. The key difficulty was determining how to create greater 

6 efficiency in the reinsurance market, whether by introducing new instruments (like swaps), 

7 bringing new capital to the market, connecting more buyers to more traders, or reducing the cost 

8 of placing reinsurance. It was determined that the above concept could be implemented in an 

9 electronic trading system that could play an important role in promoting these factors, and could, 

10 in fact, transform the reinsurance market, which is not very automated. A system that allowed 

11 trading was developed and implemented. A more detailed description of this system, as 

12 enhanced in accordance with various inventive principles herein (referred to as "first-generation" 

1 3 complex instrument trading technology), are provided below. 

14 More generally, as electronic commerce (and business-to-business commerce, in 

15 particular) has grown, various companies have developed software tools and services to facilitate 

16 transactions on the Internet and over private networks. E-Bay, for example, hosts a well-known 

17 web site that operates a transaction model (a so-called "concurrent auction") that permits buyers 

18 to submit bids on items offered by individuals. Lotus Notes provides a network-oriented system 

19 that allows users within a company to collaborate on projects. Oracle Corporation hosts various 

20 transaction engines for clients that pay to host such services on a web site. DIGEX Corporation 

21 similarly hosts web-based application programs including various transaction engines. Other 

22 companies sell so-called "shrink wrap" software that allows individuals to set up web sites that 

23 provide catalog ordering facilities and the like, 

24 Some Internet service providers, such as America Online, host "chat rooms" that permit 

25 members to hold private discussions with other members who enter various rooms associated 

26 with predetermined topics. A company known as blueonline.com hosts a web site that facilitates 

27 collaboration on construction projects. Various virtual private networks have been created to 

28 facilitate communication among computer users across the Internet and other networks, but these 

29 networks provided very limited functionality (e.g., e-mail services); are not user-defined (they 
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1 must be created and installed by system administrators); and they cannot be easily destroyed 

2 when they are no longer needed. 

3 The aforementioned products and services are generally not well suited to facilitating 

4 complex electronic transactions. As one example, most conventional services are predefined (not 

5 user-defined) and are centrally administered. Thus, for example, a group of companies desiring 

6 to collaborate on a project must fit their collaboration into one of the environment models 

7 provided by an existing service provider (or, alternatively, build a custom system at great 

8 expense). 

9 Suppose, for example, that a group of high school students needs to collaborate on a 

10 research paper that requires soliciting volunteers for a survey on drug use, conducting the survey, 

11 brainstorming on the survey results, posing follow-up questions to survey participants 

12 anonymously, publishing a report summarizing the results, and advertising the report for sale to 

13 newspapers and radio stations. This project requires elements of communication among persons 

14 inside a defined group (those writing the paper) and outside the group (e.g., survey participants); 

15 conducting research (conducting the survey, compiling the results, comparing the results with 

16 other surveys published by news sources; and brainstorming on the meaning of the results); and 

17 conducting a commercial transaction (e.g., publishing the survey in electronic form and making it 

18 available at a price to those who might be interested in the results). No existing software product 

19 or service is available to meet the specific needs of this research team. Creating a user-defined 

20 environment including tools and communication facilities to perform such a task would be 

21 prohibitively expensive. Even if such a tailor-made environment could be created, it would be 

22 difficult to disassemble the environment (computers, networks, and software) after the project 

23 was completed. 

24 In short, there is a need to provide a user-defined collaborative environment that is 

25 tailored to the needs of particular groups that conduct communication, research, electronic 

26 transactions, and deal-making. 

27 SUMMARY OF THE INVENTION 

28 A first embodiment of the invention, referred to as a complex instrument trading engine 

29 (CITE), facilitates negotiation between two or more parties. In this embodiment, a set of 

30 negotiation tools and techniques such as anonymous email, secure communication, document 
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1 retention, and bid and proposal listing services are provided in order to facilitate the negotiation 

2 and execution of complex instruments such as contracts between corporations, governments, and 

3 individuals. 

4 A second embodiment of the invention, referred to as a dynamic collaborative 

5 environment (DCE), allows members of a group to define a dynamic virtual private network 

6 (DVPN) environment including user-selected tools that facilitate communication, research, 

7 analysis, and electronic transactions both within the group and outside the group. The 

8 environment can be destroyed easily when it is no longer needed. Multiple environments can co- 

9 exist on the same physical network of computers. 

10 Although the two embodiments are described separately for ease of comprehension, it 

11 should be understood that the two embodiments share many features and, in fact, the second 



12 embodiment could include some or all of the features of the first embodiment in a generalized 

13 collaborative system. Consequently, references to a specific embodiment in the following 

14 description should not be deemed to limit the scope of features or tools included in each 

15 embodiment. Moreover, references to specific applications, such as the reinsurance industry, 

16 should not be deemed to limit the application of the invention to any particular field. 

17 BRIEF DESCRIPTION OF THE DRAWINGS 



18 FIG. 1A shows a four-step model of deal making including meeting, analysis, negotiation, 

19 and closing the deal. 

20 FIG. IB shows contract formation among a group of parties to a contract. 

21 FIG. 2 shows a listing display system showing all offers for contracts and responses 

22 thereto. 

23 FIG. 3 shows details of a listing that has been selected by a user. 

24 FIG. 4 shows one possible implementation of a reply card definition screen. 

25 FIG. 5 shows one possible implementation of a document management screen. 

26 FIG. 6 shows one possible implementation of a screen indicating persons having access to 

27 a shared folder. 

28 FIG. 7 shows a list of consummated deals in the system. 

29 FIG. 8A shows detailed information regarding a completed trade. 
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1 FIG. 8B shows a deal summary including structured and unstructured information 

2 concerning the deal. 

3 FIG. 9 shows a "flip widget" in a first state. 

4 FIG. 10 shows a "flip widget" in a second state. 

5 FIG. 9A shows a more detailed example of a "flip widget" in a first state. 

6 FIG. 10A shows a more detailed example of a "flip widget" in a second state. 

7 FIG. 1 1 shows method steps that can be carried out to define, create, and destroy an 

8 environment according to a second embodiment of the invention. 

9 FIG. 12 shows one possible system architecture in which various principles of the 

10 invention can be implemented, 

11 FIGS. 13A through 13C show one possible user interface for creating a group and 

12 identifying group members. 

13 FIG. 14A shows one possible user interface for selecting group members from one or 

14 more lists. 

15 FIG. 14B shows one possible user interface for selecting group members by composing 

16 invitations. 

17 FIG. 14C shows one possible user interface for selecting group members by composing 

18 an advertisement. 

*9 FIG. 15 shows a banner advertisement 1501 displayed on a web site, wherein the banner 

20 advertisement solicits participation in a group. 

21 FIG. 16 shows one possible user interface for selecting communication tools to be made 

22 available to group members. 

23 FIG. 17 shows one possible user interface for selecting research tools to be made 

24 available to group members. 

25 FIG. 18 shows one possible user interface for selecting transaction engines to be made 

26 available to group members. 

27 FIG. 19 shows one possible user interface for selecting participation engines to be made 

28 available to group members. 

29 FIG, 20A shows an authentication screen for group members to gain access to a newly 

30 created environment. 
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1 FIG. 20B shows a web page generated for a specific user-defined environment, including 

2 tools available to group members having access to the environment. 

3 FIG. 21 shows one possible method of generating environments in accordance with 

4 various aspects of the present invention. 

5 FIG. 22 shows one possible data storage arrangement for storing and manipulating brain 

6 writing cards. 
7 

8 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

9 A. COMPLEX INSTRUMENT TRADING ENGINE EMBODIMENT 

10 A first embodiment of the present invention provides a second- generation version of a 



11 complex instrument trading system. The second-generation system includes specialized tools 

12 that were not included in the first version of the prior art CATEX insurance trading system 

13 described above. These tools represent a substantial improvement over the first generation and 

14 incorporate new concepts of communications in a trading environment, and other capabilities 

15 that did not exist in the first generation technology. In addition, it is believed that many of these 

16 tools are also applicable to software systems other than the Complex Instrument Trading Engine 

17 or Negotiating System (CITE) described herein. Thus, the inventive principles are not limited to 

18 trading systems for complex instruments, nor even to trading systems in general. 

19 Primarily, the tools described herein ameliorate certain difficulties associated with trading 

20 of complex instruments. Complex instruments are instruments where there is more than one 

21 dimension for negotiation. As compared to such instruments as securities, complex instrument 

22 transactions take longer to research and consummate and require more extensive documentation. 

23 For example, stock trading employs a simple instrument (a share) and negotiation focuses on one 

24 dimension (price) while insurance contracts have many dimensions (term, price, coverage, 

25 definitions of perils, etc.). The stock market is relatively simple to automate - as soon as bid and 

26 asked prices match, the deal is concluded in an instant according to the rules of the exchange. 

27 Automation of complex trading is much more difficult, since the parties must negotiate and reach 

28 agreement on multiple dimensions and document that agreement using an instrument specific to 

29 the precise agreement. Automation of complex instrument trading is more difficult in every way 

30 . than trading simple instruments. 
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1 The trading model behind the Complex Instrument Trading Engine or Negotiating System 

2 is built arounil a simple, four-step model of deal making. Referring to FIG. 1A, the steps are as 

3 follows: 

4 1 . Meeting: Potential buyers connect with potential sellers with reciprocal interests. This 

5 connection does not mean that a deal will necessarily be concluded but simply that the two 

6 parties have some basis for continuing discussion. In simple instrument trading, it is typically 

7 only necessary to advertise quantity and price offered or sought. Offers for complex instruments 

8 must include substantially more detail and (frequently) extensive attachments or exhibits. 

9 2. Research/ Analysis : Each company considers its own position and/or offer and the 

10 counter party's position. Using information and analytic tools from various sources, including 

11 internal resources and resources provided by or through the trading system, each party does 

12 research and refines its position. The multiple dimensions of complex instruments increases the 

13 analytical complexity and limits the value of a simple market price. As indicated by the arrows 

14 in FIG. 1, this step is usually performed iteratively with the negotiation. 

15 3. Negotiation: Parties to the negotiation speak directly and exchange whatever 

16 information is necessary to advance the deal. As indicated by the arrows in FIG. 1A, this step is 

17 usually performed iteratively with the research step. 

18 4. Close : the companies negotiate and sign an instrument that documents the deal. This 

19 can be a complete and detailed contract, or it may be a simple memorandum. In simple 

20 instrument trading, the actual trade agreement is often standardized by the exchange. In complex 

21 instrument trading, the agreement must be more specific to the deal, though it is possible to use 

22 such tools and fill-in-the blank forms. 

23 Within a system using these complex instrument tools, trading parties can place offers to 

24 buy, sell, or trade in a public area, and examine such offers ("listings") posted by others. Using 

25 advanced communications tools the parties can conduct initial discussions to determine if a 

26 placement is possible. Using tools described herein, the initial contact can be done anonymously. 

27 If a deal seems possible, the system preferably provides access to the extensive 

28 information necessary to assess the possible deal. This can include static information (e.g. 

29 reports or data) maintained within the system, links to information providers outside the system, 

30 online analytical tools, and links to providers of analytical services. 
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1 For complex instruments, the process of negotiating a deal is contemplated to be an 

2 iterative one, with successive stages of analysis and discussion. The need for extensive 

3 communication is one of the critical distinctions between trading of simple instruments (e.g. 

4 retail sale) and complex instruments. Complex instrument trading requires dialog and more ~ 

5 exchange of documents (often voluminous), consultation with counsel and intermediaries, 

6 conferencing, and working together on the final agreement. For electronic commerce to have an 

7 impact in complex instrument trading, it must support and facilitate this communication, and not 

8 force traders to fall back on methods and technology outside the electronic trading environment, 

9 The final step is closing the deal. The companies can negotiate a contract online. Tools 

10 provide sample, fill-in the blank contracts and memoranda of understanding as a starting point. 

11 Negotiators can begin with these, or they can use one of their own. Collaborative software 

12 makes it possible to display text simultaneously on each negotiator's screen and to work on the 

13 language together. When the contract is final, the system allows for secure, online signature, 

14 though companies not comfortable with electronic signature for very large deals may print a hard 

15 copy and sign it conventionally. 



16 By creating electronic exchanges for complex instrument trading, the CITE tools can have 

17 a fundamental and positive impact on many areas of commerce: 

18 L An electronic exchange makes it possible to put an offer in front of more people more 

19 quickly than could be informed through direct contact, even allowing for active intermediaries or 

20 brokers. 

21 2. Traders can advertise and conclude deals without the need for an intermediary when 

22 they have adequate support or internal resources. 

23 3. Through better communications, wider exposure for offers, and the first steps towards 

24 standard contract language, electronic trading of complex instruments can substantially reduces 

25 transaction costs. 

26 4. With lower transaction costs, it is possible to conclude deals that were not possible 

27 with higher overhead. 

28 5. Through the immediate posting of the results of trades, pricing is moved towards a 

29 market basis, reducing research and analysis costs enormously. This speeds placement. 
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1 6. Smaller exposure means lower risk, and market pricing is an adequate surrogate for 

2 analytically derived pricing in some circumstances. Together these factors make it possible for 

3 traders to participate in markets or market segments in which they would not normally do 

4 business. 

5 7. By making it possible for all companies, large and small, to talk directly to each other, 

6 electronic trading of complex instruments can lead to the democratization of the marketplace 

7 increasing competition. 

8 Overall, electronic trading of complex instruments has the potential to improve the 

9 efficiency of markets enormously, and to establish markets in areas of commerce that are 

10 currently done through intermediaries or on a one-on-one basis. The trading tools described 

1 1 herein are designed to facilitate electronic trading of complex instruments. The first-generation 

12 complex instrument trading tools broke new ground in the extension of electronic commerce into 

13 new and more complicated markets. The table below summarizes the areas of new and improved 

14 technology, organized into the four steps of the general complex instrument trading model. 



Phase 



Meet 



First Generation 

Complex Instrument Trading 

Technology (PRIOR ART) 



Operates on private network 
only 

Post a listing to board by filling 
out a form 

Display listing summary in a 
table 



Search listings by key word 



Post response to listing on 
board 



Advanced 

Complex Instrument Trading 
Technology 



Operates on private network 
or over the Internet 
Post listing to a board by 
filling out a form 
Listings and responses can 
have attachments and 
documents 

Display listing summary in a 
table, with sorting by title, 
date, market type, buy/sell, or 
listing number. 
Search listings by keyword 
Register keywords with an 
electronic "agent" that 
monitors listings and sends 
notice of relevant new listings 
by Email 

Post response to listing on 
board 

Send private response 
(anonymously or with name 
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• Establish communications with 
lister by following up on contact 
information in listings using 
unconnected communications 
tools 


attached). 

• Response can be through a 
"reply card" designed by the 
trader posting a listing, to 
structure responses 

• Direct connection between 
listings and communications 
tool 


Analysis 


• Internet access to research 
resources, on line and third- 
party analysis 


• Internet access to research 
resources, on line and third- 
party analysis 

• Research resources searchable 
using the same search engine 
and display as used for 
listings. 

• Online dialogs / user groups 


Negotiation 


• Requires private network 

• Directory of contact information 
for all traders 

• Connection between directory 
and Email client. 

• Directory not linked to other 
components of the system 

• Anonymous mail application 
providing for communications 
between two individuals 

• Anonymous mail delivered to 
mail client 

• No attachments for anonymous 
mail 

• No system for central repository 
of documents 


• Works on Internet or private 
network 

• Directory of contact 
information for all traders. 

• Direct connection between 
directory and Email client 

• Direct connection between 
directory and online 
conferencing software 

• Directory linked to listings 
and document management 
tool 

• Anonymous mail application 
providing for communications 
between individuals or groups 
of people working together 

• Anonymous mail does not 
require separate Email client 
software 

• Anonymous mail supports 
attachments 

• Internet-based system for 
distributions and sharing of 
documents. 

• Password and secure has 
protection for documents. 


Closure 


• Requires private network 

• Online signature of uploaded 


• Internet or private network 

• Online signature of uploaded 
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and archiving of all 
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2 Referring to FIG. IB, one aspect of the system within the framework of the 

3 negotiation/analysis loop shown in FIG. 1, is the ability to define one or more contracts, for 

4 example, in the parlance of the reinsurance trade, "slip sheets." Various members of a group of 

5 authorities modify the contract causing it gradually to take a final form that is either rejected as 

6 untenable or accepted as a finalized deal. The system exposes various aspects of the contract and 

7 attendant documents to the appropriate participants in the transaction, also providing each with a 

8 level of authority to add, delete, or modify documents as well as the evolving contract or 

9 contracts (assuming there may be various contract templates being discussed). These filters 

10 (filter 1 through filter 4, for example), as shown in FIG. IB, determine the authority of the party 

11 (Party 1 -Party 4) to modify or see the data object, whether it is a document or a slip sheet. The 

12 system combines this system of filters with signature technology for closing the deal; that is, 

13 implementing signatures so that an enforceable contract is generated. 

14 A deal is like any other data object and once it is defined and entered, it cannot be 

15 modified. Elements of the deal can be "signed" such as documents attached to a contract (for 

16 example, Contract 1 has documents Dl and D2 attached to (combined with) it. Together these 

17 elements, the contract and the attachments, define the deal. Also, the entire deal 245 can be 

18 signed using a signature device ("widget") S8. Other documents may relate to a deal but not be 

19 attached. These can be viewed using a document manager described further below. 

20 Listing System 

21 Referring to FIG. 2, a listing screen displays all offers for contracts, for example offer 

22 314, as well as responses to them, for example, response 313. The parameters of the offers and 

23 responses to them are shown in columns, the heading of each of which may be selected to sort 

24 the listings by that heading, for example heading 315 if clicked would sort by the unique index 

25 number for the listing. Notice that the responses (for example, response 313) are shown indented 

26 % to indicate a series of elements of a dialogue-thread. As indicated, the responses have a 
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1 "daughter" relationship to the parent listings. That is/listing 314 is a parent and reply 313 is a 

2 daughter. The daughters remain in their hierarchical position beneath the parent despite sorting 

3 by the column headings. This makes the tabular sort scheme compatible with a threaded display, 

4 which is useful to show dialogues. 

5 Referring now also to FIG. 3, when a user invokes a display of the details of a listing by 

6 clicking on an index hyperlink 312 to show the details of the listing, a user interface element 

7 displays the lister's defined parameters of the listing. As shown, various parameters are 

8 displayed, many of which are hyperlinked. For example, attachments 304 may be selected to 

9 display the corresponding attachments. A detailed description 301 may be provided as well as 

10 specific instructions for responding 302. A reply button 303 permits the user to reply. 

1 1 Activating the reply button 303 will either invoke a standard public reply screen which creates a 

12 new listing similar to the parent listing or a special reply defined by a reply card which is further 

13 described below. 

14 A reply to a listing can take the form of a public reply that invokes a screen substantially 

15 the same as FIG. 3 but with blank spots for entry of reply information. A more useful kind of 

16 response element is a reply card that can be defined by the lister. This is because in negotiations 

17 on complex transactions such as reinsurance contracts and, for example, pollution emission 

18 allowances, the parties with whom a lister would be willing to trade are limited in terms of 

19 certain criteria. These criteria will vary from one type of transaction to another. 

20 In an active trading system, the number of listings can quickly grow to a large number 

21 and quickly exceed the number which can conveniently be displayed in a single table. Several 

22 capabilities are built into the system to address this problem. First, by default, listings are 

23 presented in order from newest to oldest. Second, the sort capabilities previously described 

24 allow users to modify the standard order. Third, the total market may be divided into 

25 subcategories. In the area of insurance catastrophe risk, these could include categories for 

26 different lines of insurance (e.g. marine, aviation, commercial buildings). Fourth, users may 

27 enter search criteria to identify a subset of listings of particular interest. 

28 Searching listings: A user may enter a keyword such as "hurricane" to identify all listings 

29 that contain that word in the title, description, and (optionally) attachments. To improve the 

30 reliability of the search, users are provided access to a standard lexicon when composing a 
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1 listing. In the first embodiment, this capability is invoked by pressing the right mouse button 

2 while the cursor is any field of the listing. A list of common terms is displayed. The user can 

3 select the term of interest, which is then placed into the text of the listing at the insertion point 

4 marked by the cursor. For example, a listing for insurance risk would typically include a field 

5 for geographic scope (i.e. the location of the properties to be insured). When in this field, the 

6 lexicon displayed would include terms such as "California" and "Coastal Florida". Choosing a 

7 term from the lexicon insures uniformity of terminology across listings and between the search 

8 engine and the listings. "California" will be used rather than a mix of "Ca", TA", "Calif, etc. 

9 The search is further improved by symantic indexing. Essentially, this means that synonymous 

10 terms are grouped, so that searches for one will find the other. A person who searches for 

1 1 "California" will get listings for "Los Angeles" that do not include the word "California". 

12 The search engine can include an agent capability. This agent capability offers the user 

13 the option of saving a search, after the user reviews the results and deems them acceptable. This 

14 search is retained in a library of searches along with the email address of the owner of the agent. 

15 The search is retained in the library until is it either deleted by the user when it is no longer 

16 needed or automatically deleted in a cleanup of searches older than a certain date. Whenever a 

17 new listing is placed on the system, all of the saved searches are executed. If the new listing 

18 meets any of the search criteria, a message is sent to the owner of that criterion via email or 

19 instant messaging. 

20 A model was developed to allow a lister to define a set of criteria and request a set of 

21 information from any respondents in the form of an anonymous reply "card." The card defines a 

22 set of requested information which may be packaged as a document object and placed in the 

23 document manager system and connected with each listing. A user would download the reply 

24 card and fill the card out and send it back to the posting party. 

25 A document object, called a reply card, is made available to a respondent through the 

26 document manager. The respondent is permitted to retain his anonymity as is the lister. Each 

27 may communicate with the other through an Amail system described in more detail below. The 

28 respondent supplies the requested information and sends the data to the lister. A system in the 

29 listing manager allows a lister to define a reply card having any particular fields and instructions 
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1 required of a respondent. Some of the information required may be obtained automatically from 

2 a set of default data stored on the respondent's computer. 

3 Referring to FIG. 4, a reply card definition screen is invoked to define the parameters of a 

4 new listing. The new listing is defined using a user-interface element looking much like FIG. 3. 

5 While the details are not critical, the definition of reply card involves, in essence, the definition 

6 of a user-interface control such as a dialog with radio buttons, text boxes, etc. These are 

7 definable for server-side implementation through HTML and are well known so the details are 

8 not discussed here. The lister defines a set of controls that allow the entry by a replying party of 

9 the information that the lister requires. The reply card is stored as any other information object 

10 and may be organized and accessed through the document manager described below. FIG. 4 

1 1 shows a simple example of a format of a reply card. 

12 A reply card is created by a user when posting a new listing. The lister specifies the 



13 information that must be included in a response, and the type of information object to display for 

14 the data element (e.g. a text box, check box, radio button). The system then creates an HTML 

15 page to collect the requested information. When a respondent clicks "Reply Card" on the listing 

16 screen, the page is displayed. All of the responses are automatically entered into a database 

17 created automatically when the reply card is composed. As each respondent fills out a reply card, 

18 a new record is added to the database of the system and the lister is permitted to view it through 

19 an appropriate filter as discussed above. 

20 Signature System 



21 As business is increasingly done in an electronic environment, electronic signature and 

22 approval is becoming more critical. The typical electronic signature model has focused on two. 

23 aspects: 

24 1. Electronic validation of the user - specifically determining that the person viewing a 

25 document on line is the authorized signatory; and 

26 2. Validating the document being signed by a means that either prevents modification of a 

27 document or will reveal whether changes have been made. 

28 Methods for validation of identity range from simple personal identification numbers or 

29 passwords, to electronic signature pads, and more advanced methods of biogenic validation such 

30 as fingerprint or retinal patterns. Methods for document validation range from simple archiving 
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1 of one or more copies in a read-only model or inaccessible location to methods based on 

2 mathematical algorithms that create a characteristic number or alphanumeric string for a 

3 document. These strings are termed "electronic signatures." Changes to the document change 

4 the electronic signatures. Because the signatures are much shorter than the documents, very 

5 many documents have precisely the same signature, but the algorithms to calculate the signature 

6 are very difficult to invert, so that it is effectively impossible to deduce a meaningful change to a 

7 document that will preserve a specific signature. 

8 These two aspects of electronic signature are highly developed, but there has been little 

9 analysis or development of the general process by which documents can be signed. 

10 The invention allows for secure and reliable routing of documents, for which signatures 

11 are required, to a specified list of signatories. Unlike prior art systems, such as ordering or 

12 accounts payable systems which have highly structured signature procedures tailored to a specific 

13 process, the present invention provides a flexible method and system that allows a signature-type 

14 of authority/requirement to be attached any kind of information object. The method is sufficiently 

15 abstract, flexible, and general that it can be applied in many contexts aside from the CITE 

16 embodiment described in the present specification. 

17 One signature method/device employs the following steps: 

18 1. Registration of signatories - This process provides a register of identifiers indicating entities 

19 with signatory authority and correlates these identifiers with the information objects for which 

20 the signatory authority is applicable. The same register may also be used to identify other types 

21 of authority in the system in which the signature device is implemented. For example, document 

22 read authority, modification authority, exclusive access to documents, etc. may also be provided 

23 in the same register. Signature registration may be provided automatically in certain systems 

24 where registration of, for example, read/write authority is provided since any entity with 

25 signatory authority would in almost all instances, also be provided with some other kind of 

26 authority, most notably, read authority. Thus, where the signatory system is embedded in certain 

27 kinds of systems, it may be that no particular additional method or device is required to 

28 implement signatory registration since an existing register may already exist or be required for 

29 other purposes. 
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1 Registration information includes the general categories of information listed below. 

2 Definitions of specific fields within these categories are a function of the specific implementation 

3 of the signature system or the parent system. The following are exemplary: 

4 1. Identity - unique identifier of the entity, the organization(s) with which the entity is 

5 affiliated, other relevant information. 

6 2. Contact information - information indicating how the entity can be reached, how 

7 documents and mail messages can be routed to the entity. 

8 3. Security Information - a password for each class of signature as described further 

9 below. 

10 2. Classes of signatures - The device/method provides a variety of classes of signature, each 

1 1 associated with a unique level of approval or level of commitment. For example, a class of 

12 signature-authority can be defined that represents individuals, for example, with authority to sign 

13 contracts only below a set amount, or for expenses relating only to one department of an 

14 organization, or within certain time constraints, etc. The signatory system maintains this 

15 taxonomy of possible signature types in a database with a unique identifier for each level of 

16 authority defined. The system allows the creation and deletion of classes. Each class is 

17 preferably permitted to be named and a descriptive definition attached to each class. 

18 3. Defining a Set of Signatures - Using an appropriate user interface element, the user of the 

19 system selects an information object (for example, a document, file, or collection of such objects) 

20 requiring signature(s). The entity originating the signature process then identifies the entity or 

21 entities required to sign the object. The specification of the signers can proceed either by the 

22 selection of individuals from a list supported by the above defined entity register. Alternatively, 

23 in an environment where individuals are strongly bound to organizations, for example, it can 



24 proceed by selecting the list of organizations that will sign and, within each organization, the 

25 person who will sign. The list is built by a series of selections. After each selection from the list, 

26 the user indicates his/her desire to add the selected individual to a list of required signatories. 

27 The user interfaces provides for entries in which all the selected signatories are required or only 

28 one of the selected signatories are required. 

29 For example, if more than one entity is selected from the list prior to the selection (e.g., 

30 clicking an "Add" button), the system may require a signature from any of the people selected, 
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1 but not all of them. To require signature from every member of the group, the initiator may 

2 select one person, then "add", select the second, then "add", and so on. Thus, adding a group 

3 with one "add" command would provide an "any signature will suffice" list and adding members 

4 individually would require a signature from that individual or entity. Note that this technique 

5 may also be used to define combinations of required and "any of groups. 

6 For each signer or group of signers selected in a single "add" command, the initiator of 

7 the signing sequence must specify the class of signature associated with the person for the 

8 document being signed. This may be selected from a list of signature classes (see item 2). If the 

9 specific implementation of the signature process only supports one class of signature, the 

10 selection of class may be omitted. 

1 1 4. Random or Serial Order of Signature - After or concurrent with the creation of a signature 

12 list, the initiator specifies whether signatures must be in order or if a specific order is not 

13 required. For purposes of defining the order of signature, individuals who are selected as a group 

14 are considered as occupying a single place in the sequence. 

15 5. Document Authentication - Upon initiating a signature sequence, the information object is 

16 authenticated by means of a secure hash algorithm. The specific hashing algorithm is a matter of 

17 design choice or may made dependent on a user's choice. There are several possible hash 

18 algorithms available in the public domain. The electronic signature produced by the secure hash 

19 algorithm is archived with the information object in a secure repository. If the information object 

20 is, for example, a record in a database, the contents of the record are copied to a file in delimited 

21 format for archival purposes. If the object is a table, the table is exported prior to archive. 

22 6. Document Routing - Upon initiation of a signature sequence, the initiator specifies how the 

23 signatories are to be informed. The options are: 

24 • No notification from the signature system 

25 • Email message 

26 • Email message with attachment of the information object. 

27 • Posting on a signature web site 

28 The system accepts and implements the chosen method, which may be connected to the signature 

29 or a single choice applied to all signatories. Alternatively, the method of notification may be 

30 stored with the signature class definitions. In a signature process with no required order, e-mail 
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1 notice may be sent simultaneously to all of the designated individuals at the time of initiation. If 

2 the process is serial, only the first person may be notified. The electronic signature of the 

3 information object may be included in an e-mail message. 

4 7. Accessing the signature system - The signature system can be implemented for access via a 

5 web browser or database client-server software across the Internet, an intranet, a LAN, or a 

6 WAN. Access to the system will typically require a password, but this may not be necessary on a 

7 secure network. Upon access to the system a user will have the option to display a list of all of 

8 the information objects which he or she has signed or is being asked to sign. For each object, the 

9 display can include the following information: 

10 • Object name 

1 1 • Description of object (text, mime, size, date) 

12 • List of scheduled signatories 

13 • Date each person signed 

14 • Class of signature for each person 

15 • Electronic signature produced by the secure hash algorithm 

16 If the object is available (viewable) on line, the display may also include a link to display or 

17 download the object. 

18 8. Validation of the Object at Time of Signature - If the user downloads or views the object, the 

19 system will execute the secure hash algorithm to calculate the electronic signature. This will be 

20 displayed so that the potential signer can compare it to the signature calculated at the time the 

21 process was initiated. If the user has previously downloaded the object or received it as an 

22 attachment to an Email, the user may access the secure hash code through the signature system 

23 and apply it to the version on the user's disk. 

24 9. Signing a Document - After the user has determined that an information object is authentic 

25 and that the contents merit signature, he or she can affix a signature by authenticating his or her 

26 identity. Various means of authentication may be used. The means of authentication may be at 

27 the discretion of the manager of the signature system. Such means may include personal 

28 identification numbers, passwords, authentication based on computer address or information 

29 stored on the signer's computer, third party validation using a public key or other security 

30 infrastructure, or biogenic (fingerprint-recognition, retina scan) methods. 
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1 After a document is signed, the date of signature is recorded in a database so that the 

2 display to other potential signers is updated. If the signature process is serial, the next person in 

3 the sequence is notified. E-mail notice can be sent to all, signers when the last signature is 

4 collected. 

5 10. Follow-up - At the time a signature process is initiated, the initiator can select a time (in 

6 hours, days, or a time or date-certain) for automated follow-up. If a document is not signed 

7 within the specified period after notice, a follow-up e-mail can be sent as a reminder. Additional 

8 reminders may be sent at the same interval if the object has not been signed. The reminders can 

9 be sent automatically by the system according to user-input specifications. 

10 11. Cancellation - The initiator of a signature sequence can modify the sequence at any time, 

1 1 except that a signer can not be deleted from the list once they have signed an object. 

12 12. Transfer of authority - The individual initiating a sequence can transfer the right to modify 

13 the list signature list to another individual in the system with appropriate validation of identity. 

14 Document Manager 

15 Successfully conducting commerce over an electronic network requires the exchange not 

16 only of messages, but of substantial blocks of information in the form of documents and data. 

17 Beyond simply transferring files from hand to hand, it is often necessary for multiple parties to 

18 work on a document simultaneously or serially, to track changes, and to maintain a record of 

19 versions. Two general architectures have emerged for document management, which can be 

20 termed a "mail model" and a "repository model." Under the mail model, documents are attached 

21 to messages and circulated person to person. Under the repository model, documents are placed 

22 in a central location. There are advantages and disadvantages to each. At a summary level: 



Mail Model 



Repository Model 
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Advantages 


Precise routing on a document 
specific basis. Push in the 
recipient is informed of a new 
document. Coupling between 
document flow and a messaging. 
Dating is automatic. 


Compact storage - only 
one version of a file need to 
be stored. Natural group of 
files on the basis of subject 
or access group. Supports 
good configuration 
management and version 
control. 


Disadvantages 


Creates multiple versions of a 
document, confounding 
configuration management and 
version control. Does not easily 
couple to online collaboration. 
Many mail servers limit size of 
attachment. Relatively high 
effort to prepare messages. 


Not push in the sense that 
users are automatically 
informed of new 
documents. Security model 
is more complicated than 
for email. Prior 
arrangement is necessary to 
access a repository. 



1 

2 A browser-based document management model and tool combines the best features of 

3 repository model and the mail model, for document dissemination and sharing across the Internet 

4 or an intranet. 

5 General Architecture - The general architecture of the system combines two basic components: 

6 (1) a database of directories and documents and (2) a directory of users. The directory of 

7 documents lists documents (of any type) contained in the system, and folders that can contain 

8 documents or other folders. The directory of users contains a list of individuals and 

9 organizations that can access the system, with passwords and/or other information necessary to 

10 validate identity and to establish authority. 

1 1 Representation of document - The term "document" is used here in the broadest sense of any file 

12 that can be stored magnetically or electronically. Preferably, each file is given a unique name 

13 consisting of a string of no more than 256 characters. Preferably, the character set is limited to 

14 those members of the ASCII character set which are displayable or printable. Thus, such codes 

15 as "escape" which have no visible representation, would be excluded. This is the file name that 

16 is displayed for purposes of identifying the document to the users. There is also an actual file 

17 name (which is not shown to users) to identify where copies of the file are stored in the central 

18 repository. Certain other information is kept in addition to the name of the file. This includes 

19 the following: 

20 1 . Data of creation 
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1 2. Date entered into repository 

2 3. Person who entered the document into the repository 

3 4. Description 

4 5. Size of the document 

5 6. Document type if known 

6 7. Date of last update 

7 8. Access password (optional) stored in encrypted form 

8 9. File f older (s) where the document appears 

9 10. Actual file name 

10 In addition to the above information, data indicating whether the file is checked-out and 

11 to what entity, and the identities of entities that have checked the document out and returned it in 

12 the past are also stored. The term "checking out" is described further below. These functions 

13 related to file change control and configuration management, which are discussed later. 

14 User database - A database contains information on all individuals who can currently access the 

15 system or who previously had access up to an administratively determined retention period. This 

16 database includes standard contact information including physical and electronic addresses. 

17 Security data such as passwords and/or encryption keys is also maintained. In a combined system 



18 such as the presently described system, the same database or registry of users can be employed 

19 for the document manager as for the signature system. 

20 High level directories - The entire document management system can be divided into a number 

21 of high level directories that the user can display, one at a time. These include, at a minimum, a 

22 "Private" directory of files and folders visible only to the user, and a "Public" directory of files 

23 and folders visible to all users. Additional high-level directories can be created by the system 

24 administrator as needed. These could correspond to projects, business units, or any other logical 

25 basis. At any point in the use of the document management system, a user can see and select 

26 from the high level directories to which the user has access. The name of the currently open 

27 directory can be always displayed on the screen. 

28 Displaying the contents of a high-level directory - When a user selects a high-level directory, the 

29 repository displays a series of file folders against the left margin of the active window. File 

30 folders whose contents are displayed are shown as open folders. File folders who contents are 
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1 not displayed are shown as closed folders. A folder is opened or closed by clicking a single time. 

2 When a folder is opened, the contents are shown with an indent to indicate the parent/child 

3 relationship between the folder and its contents. Each folder can contain files, shown by an icon 

4 representing a printed page and other folders, represented by an image of a closed folder. 

5 Information about a folder - Information about each folder is displayed on the same line, to the 

6 right of the folder icon. This information is as follows, from left to right: 

7 1. Name of the folder 

8 2. Number of files in the folder, or the word "empty" 

9 3. Accessibility of the folder 

10 Accessibility refers to user access rights to a folder which may private relative to the entity that 

1 1 created it, restricted (limited to a subset of people who can access the high level directory), or 

12 shared (available to everyone with access to the high-level directory). The level of access to a 

13 directory is indicated by the words "private", "restricted" or "shared." 

14 If the directory is restricted, clicking on the word restricted displays a list of the entities 

15 that have access to the folder. This list is a series of hyperlinks. Clicking on the name of a 

16 person pulls up detailed contact information (discussed below). The objective is to facilitate 

17 communications between people with a shared interest in a file. 

18 Information about a file - Information about a file is displayed to the right of the file icon. From 

19 left to right, the first item displayed is the name. This is followed by the word "details." Clicking 

20 on "details," causes the document management system to display complete information about the 

21 file (see Item 2, above), the person who placed the document in the file, (see Item 3, above), and 

22 the person who most recently modified the file. 

23 Information about people/entities, and the link to communications - Information about 

24 people/entities with access to the system is displayable at several points in the document manager 

25 system: 



26 L by accessing the directory of users 

27 2. when creating a new folder with "restricted" access 

28 ,3. when displaying detailed information about a file (see #7) 

29 4. when displaying information about a restricted directory (see #6) 
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1 Whenever such information is displayed, contact information from the database is rendered along 

2 with the name. Depending on the implementation, this can include complete contact info 

3 (multiple addresses, telephone and fax numbers, and email addresses), or some of the contact 

4 information may be restricted, in which case it is not displayed. 



5 Creating a new top level folder - A new folder is created within a high-level directory, for 

6 example by clicking a button labeled "new folder." This can bring up a dialog in which the user 

7 assigns a name to the new folder and selects the type of access (private, shared, or restricted) 

8 rights to be assigned. If the document is restricted, the user specifies the entities (organizations 

9 and/or people) that can access the folder. If the creator of the folder specifies that an 

10 organization has access to a folder, all individuals associated with that organization may be 

11 granted access. Folders to which a user does not have access may remain hidden or not 

12 displayed. Alternatively, these folders can be shown with some indication that they are not 

13 accessible, for example, by ghosting. 

14 Functions related to a folder - Once a folder is defined, a user can execute the following options. 



15 1. Create a subf older, using the same process described in 9 

16 2. Add a document to the folder, using the process described in 1 1 

17 3. Delete the folder, if it is empty 

18 4. Modify access to the folder using the same tools used to specify access initially 

19 The functions can be invoked by, for example, clicking on the appropriate label to the right of the 

20 name of the folder icon. 

21 Adding a file - Users add a document using a dialog box that prompts for the following 

22 information: 

23 1. Location of file - may be entered by user, or selected through a standard file browse 

24 dialog 

25 2. Name to be used for the file in the repository 

26 3. Version number or name (optional) 

27 4. Password or encryption key (optional) 

28 5. Description (optional) 

29 6. Access rules (read only or read-write) 



23 



1 After entering the above information, the user either aborts or initiates upload. The 

2 information listed above is recorded along with the name of the person entering the document, 

3 and date and time. 

4 File options - The following functions may be provided, preferably for every file in the system: 

5 1 . Delete (with confirmation) 

6 2. Archive. The file is removed from main repository, but a copy is retained outside the 

7 repository. It may be restored though manual intervention. 

8 3. View or download: a copy of the file is brought to the user's computer. This file can 

9 be modified there for the individual user's use. A modified version can be uploaded as a 

10 new file or different version of a current one, but a file in the repository can only be 
i l replaced if the user has it checked out. 

12 4. Check out / check in (see below) 

13 5. Forward (see below) 

14 6. Change Password. The old password must be entered followed by a new password and 

15 confirmation. 

16 7. Move: copy or more a document from one folder to another. 

17 The functions may be invoked, for example by clicking on a label corresponding to the 

18 function, which can be displayed to the right of the name of the file. Not all options are shown to 

19 all users. If an entity does not have write-access to a file, the entity may not delete it, archive it, 

20 check it in or out, or change the password. 

21 Check in / Check Out - AH entities with write access to a file may check it out. By checking the 



22 file out, the entity reserves the exclusive write to save changes to a file. A person may not 

23 replace a file that is checked out. To check out a file, the user selects this option from the list of 

24 functions associated with the file. The user can then enter an expected return date and a reason 

25 that the file is checked out or the changes to be made. This information is available to all others 

26 who can view the file. Each check in or check out is recorded in a permanent log. After a file is 

27 checked out, the "check out" button or link is changed to read "check in." 

28 Each indiyidual can check in only the files that he or she has checked out. This is done 

29 by clicking "check in." The user may then upload a new version of the file by specifying the 

30 location of the file on disk, or indicate that the version of the file currently in the repository is to 
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1 be retained. After a file is checked in, the check button is changed back to "check out" and the 

2 file can be checked out by another user. 

3 Forwarding - A file can be forwarded to any other user of the system. When the forward function 

4 is invoked, a list of users is displayed. The sender selects one or more users. Upon confirmation, 

5 a copy of the document is placed in folder labeled "in box" in each recipients private directory. 

6 Referring to FIG. 5, a main screen for the document manager creates (using server-side 

7 scripting) a user-interface display with some of the features of a Windows Explorer® -type 

8 display. File and folder icons are shown along with an array features arranged next to each. The 

9 similarities with Windows Explorer® fairly well end there, however. Each of the properties 

10 shown next to each file/folder entry invokes a feature. 

11 A parameter object W "Details" invokes a detailed display of the corresponding 

12 document object. The details can include contact information about the creator of poster of the 

13 document or other data as desired. This data can be hyperlinked and a return button can be 

14 provided to return the display back to the screen shown in FIG. 5. Clicking the "details" button 

15 to the right of any document brings up the display which can include the name, contact 

16 information, and other details about the person who loaded the document into the system, similar 

17 information about a person who has the document checked out, and, optionally, a description of 

18 the document and information on its change history. 

19 A parameter object X "Forward" simply sends the document to a selected user. A 

20 selection screen can be invoked to allow selection of the recipient of the document from the user 

21 registry. Of course, since most correspondence can be handled on the server side, the user is, in 

22 reality, simply notified of the transfer and the recipient's action to view the document simply 

23 invokes a server side feature to display the document. The document is not actually transferred 

24 bodily to the recipient since the recipient, as a registrant logged in the user registry, can access it 

25 through the server by requesting to do so. 

26 A parameter object U "Check-in" checks in a document that has been checked out. Other 

27 users may view the document, but not modify it when it is checked out. This button is not 

28 accessible to users that have not checked the document out and may be displayed ghosted or not 

29 displayed at all. A similar button can be displayed if a document that is not checked out may be 

30 checked out by the user authorized to see the document manager displayed shown in FIG. 5. 
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1 A parameter object T "Download" actually transfers a copy of the document to the client 

2 computer. Another object S "Delete" allows the document to be deleted. A new document can 

3 be added by clicking "New Document" Q. These are fairly conventional notions, except for their 

4 placement on the screen and the fact that each is filtered depending on the user's rights. 

5 Note that when a folder is created, access to the folder can be restricted to the creator, 



6 shared with everyone (in which case the folder is created in the public directory), or shared with a 

7 select group of other users. The other users can be selected by company or organization 

8 (providing access to all individuals in the organization) or by individual within an organization. 

9 These are all selectable through a linked selection control where if one selects a company in one 

10 selection control, it shows employees in the linked selection control. 

U A parameter object P "Shared" displays a hyperlinked page that shows all users with 

12 access rights to the document. This page allows a user that places a document in the document 

13 manager or a user that has pertinent modify rights, to alter the parties that have access to the 

14 document. Also, it allows a user with read-only rights to see the list of users that can access that 

15 document. The names of the sharing parties are hyperlinked to invoke the user's email client to 

16 allow fast sending of email (which again may be performed server-side without actual transfer) 

17 or conventionally or selectively. If a folder is shared, the word "Shared" appears to the right of 

18 the folder. Clicking on "Shared" brings up the list of person who can access the folder, as shown 

19 in FIG. 6. Each name is a hyperlink to detailed contact information. 



20 FIG. 7 shows a list of all deals that were completed through the system. The trade 

21 number (left column of the grid) is a hyper link to detailed information. 

22 FIG. 8A shows detailed information about a completed trade. It shows the party to the 

23 trade, the price or rate, and a description of what was traded. The particular nomenclature is 

24 specific to a market. For insurance, for example, price is termed rate, and the summary of a deal 

25 is the slip sheet. A complete contract can be attached. Included documents can be downloaded 

26 to view on line. The intended signatories to a deal are shown (there can be more than two). 

27 If a signatory has actually signed the document electronically, the date and time are 

28 shown. No date and time are shown for parties that have not yet signed. The amount of 

29 information displayed on the screen is dependent on the identity of the person viewing the screen. 
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1 The viewer can be blocked from viewing any information about a deal, or certain fields, such as 

2 the contract details or the name of signatories. 

3 Note that the detail screen of FIG. 8A would also show attached exhibits. The FIG. 8A 

4 display is the basic device for signing deals. A similar device would be used for signing 

5 documents. 

6 Referring to FIG. 8B, all of the information necessary to document a deal is pulled 

7 together through the screen below. The deal summary includes highly structured information on 



8 parties, dates, terms, etc., as well as unstructured information in the form of attachments. The 

9 bottom part of the page allows the person registering the deal to designate the intended 

10 signatories. When the signers affix their electronic signature, they are doing so to all of the 

11 documents in the deal, including the attachments. These are archived and protected from 

12 tampering using secure hash technology. In this way it is possible to create a reliable, on line 

13 electronic signature to a complex deal, without risk of repudiation. 



14 Note that any number of exhibits can be added to the UI device of FIG. 8B since the list 

15 scrolls from the bottom each time a second exhibit is added. The user interface has self- 

16 explanatory elements for defining information about the deal. 

17 Anonymous Mail 

18 For purposes of the following description, a "subscriber" is a person or entity that 

19 subscribes to an anonymous mail system to be described below. Certain types of negotiations 

20 and communications require anonymous initial contact, followed by some period of anonymous 

21 discourse, leading to eventual disclosure of the parties' identities. In the course of a typical sale 

22 or business deal, the initiating party begins either by contacting one or more targeted potential 

23 trading partners or advertising to a community of potential partners. While the identity of the 

24 initial offeror is usually clear in any direct contact, it need not be so in advertising. In certain 

25 cases it could be problematic for the initiating party to reveal his or her identity: 

26 A party to a deal can have difficulty controlling the method of contact once the party's 

27 identity is known. If a company is known to be in the market for office space, for example, the 

28 party may be subjected to badgering by real estate firms outside the established bidding process. 

29 Executives of the company may be contacted directly in an effort to influence the decision. 
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1 Disclosure of intent may adversely affect the market. If a large company begins to 

2 acquire land in an area, the price can rise very quickly. Simple exploration of an option can 

3 make the option more costly or even impossible. 

4 Disclosure of intent may adversely impact the reputation or standing of a company. An 

5 insurance company that determines that it is over exposed to a certain peril (e.g. hurricane losses 

6 in the Southeastern U.S.) would reveal that situation to their competitors and investors by a large 

7 public solicitation. 

8 While anonymity can be crucial for the initiator of a deal, it can be equally important for 

9 the respondent for the same reasons. The need for controlled anonymity has been addressed by 

10 several methods that were initially developed for paper communications and have been extended 

1 1 to analogues in telephonic and computer communications. 

12 • Numbered mail boxes, including government and private 

13 • Communications through a mediator 

14 • Anonymous voice mail drops 

15 • The use of pseudonyms in computer e-mail and dialogs. 

16 These methods have several serious shortcomings: 

17 • The method may only allow anonymity from one side. 

18 • There is no inherent mechanism to validate the credentials and intent on an 

19 anonymous party 

20 • Use of a pseudonym may invalidate its future use by associating the name with a 

21 specific party 

22 • Manually mediated communications are slow 

23 • The creation and deletion of pseudonyms may not be completely within the 

24 control of the party, imposing an overhead cost (in cash or labor) and/or delay in creating 

25 a new name 

26 • In most systems, a person with multiple pseudonymous mailboxes or e-mail 

27 addresses will receive communications in several different places (mailboxes or 

28 accounts), thus requiring multiple logons/passwords. 
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1 • Routing of messages received anonymously requires manual forwarding to all 

2 relevant parties by the individual with access to the anonymous mail box or email 

3 account. 

4 • There is no mechanism to reveal actual identities in a secure and mutually 

5 acceptable way. 

6 The present invention addresses these deficiencies by providing two-way anonymous 

7 communications, a central point of collection for messages sent to multiple pseudonymous 

8 addresses, connection of multiple parties to a single anonymous account, and a mechanism to 

9 reveal identities to all parties to a deal simultaneously, by mutual consent. In summary, the 

10 anonymous mail system is a server side system that allows clients to create anonymous handles 

1 1 on the fly. It also allows them to share anonymous handles among multiple recipients so that the 

12 group of recipients appears as a single recipient to the sender using the anonymous handle. It is 

13 like a transparent mailing group. When mail is sent to an anonymous handle, it is sent to all 

14 members of the group. 

15 Multiple Systems - In contrast to the first-generation anonymous mail system, the present system 

16 allows for multiple anonymous mail (Amail) systems. Each Amail system operates in 

17 association with a conventional e-mail server, and uses the e-mail server for communications 

18 with non-subscribers, subscribers to Amail systems other than the local one, and for forwarding 

19 messages to the subscribers Email client software. 

20 Registration - Subscribers to an anonymous mail system (Amail) each complete a registration 

21 that provides: 

22 • Contact information (name, address, telephone number, fax, etc.) 

23 • Information to determine whether they the party is qualified to participate in the 

24 communications exchange. For example, if the system were to be used between and 

25 among real-estate agents, registrants to the system might be required to supply a real 

26 estate license number. 

27 • Association with an organization (if appropriate) 

28 • Additional information on the individual or organization that may be of use to 

29 others in the Amail system to determine the suitability of the party as a partner in 

30 negotiations. 
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1 The additional information can include such factors as credit ratings, assets, or the region in 

2 which the company does business. The specific information required depends on the application. 

3 Insurance, real estate, energy marketing, etc. would all have different data of interest. 

4 Validation - Depending on the business model and role of the organization operating the Amail 

5 exchange, the organization can either accept the information provided by the subscriber, or verify 

6 the information and provide verification as part of the service. Upon acceptance of a 



7 subscription applications and validation of the background information if necessary, the use is 

8 assigned an Amail user ID and password. 

9 In the first version of the Amail system, logon was automatic from the general application 

10 (CATEX); there was no separate user ED and password. In alternative versions, the Amail 

11 system can provide its own user ID and password, with the ability to bypass logon when it 

12 accessed from other applications with acceptable user validation. All of the actual contact 

13 information and validation information are maintained in a database. Validation information was 



14 not provided in the first version of CATEX. 

15 Assignment of an Email address - Each subscriber must provide an Internet accessible Email 

16 address or be assigned an e-mail address in the Amail system. The first version of the Amail 

17 required that the user have an Email address on the system. The new version works directly with 

18 e-mail systems other than the AmaiL 

19 Logon - Subscribers access the Amail system by connecting an Amail web page provided either 



20 over the Internet or on an Intranet. The subscriber enters a user name and password. The first 

21 version of Amail was not browser-based and worked only over a LAN or WAN, not over the 

22 Internet or an intranet. 

23 Available functions - After logon, the subscriber can access the following functions: 

24 • Manage aliases 

25 • Compose an anonymous message 

26 • Read Amail messages. In the original CATEX system, the user could not access 

27 messages from within the Amail application. 

28 • Log off 

29 Managing Aliases - Aliases are directly under user control. After logon, a user can: 

30 • Add a new aliases 
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1 • Delete an existing alias 

2 • Create a free-form note associated with a new alias, or edit the note for an existing alias 

3 that will be accessible to recipients from the alias. 

4 • Identify other subscribers to whom messages to alias should be forwarded 

5 • Identify other subscribers with permission to generate messages from the alias 

6 These last two features make it possible for a group of subscribers to share an alias, allowing 

7 them share communications and work together more effectively. The user will: 

8 Compose an anonymous message - After logon, a user can create and send an anonymous 

9 message. After the option is selected, the system will display a message creation screen with the 

10 following features: 

11 LA list of aliases currently owned by the user (i.e. created by the user and not deleted), 

12 for the user to select the alias from which the message will originate. 

13 2. A subject box for the mail. 

14 3. A list of the e-mail and alias addresses to which messages can be sent for the user to 

15 select one or more. The original version could only send to one alias. The user can also 

16 supply an Internet e-mail address off system. 

17 4. A list of the e-mail and alias addresses to which copies of the messages can be sent for 

18 the user to select one or more. The user may also supply an Internet e-mail address off 

19 system. The original version did not include a "CC" feature. 

20 5. A space where the message can be typed, allowing for users to paste text copies form 

21 another system using the Windows-based clipboard utility. 

22 6. A check box to select whether the sender is willing to reveal his identify to the 

23 recipient on mutual consent. 

24 7. A check box to select whether the copies of the message should be sent to other 

25 subscribers who share the Alias. The original version allowed only one subscriber to 

26 access an alias. 

27 Delivery of Messages - After an Amail message has been composed (see step 7), it is delivered 

28 as follows. 

29 1. The body of the email message is modified by adding a header including routing 
30 . information and an indication of whether the sender is willing to reveal identities if there is 
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1 reciprocal concurrence. The message would appear as shown below. The items in italics are 

2 new since the original (prior art) version. The first generation of the anonymous mail system did 

3 not allow for communications between multiple Amail systems and, hence, did not list the Amail 

4 system name in the list of respondents. The first generation system also did not allow for 

5 multiple recipients. 
6 
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77».y message was sent anonymously from alias: Amail system name: alias 

The message was sent to: 

Amail system name: alias 

Amail system name: alias (cc) 

Amail system name: alias 

The sender is willing to reveal identities. 

[Original body of the message] 



2. If the message is sent to a specific, non-anonymous e-mail address, Amail composes 
and transmits a standard Email message. The sender is listed as "amail.admin.alias@xxxxx" 
where "xxxxx" is the address of the standard mail server supporting the mail system. Off-system 
access was not a feature of the first version. 

3. If a message is sent to an alias on the local or any other related Amail system, and the 
owner of the alias has an off system email address, a message is sent as in step 1, above. In 
addition, however, the message is stored in an Amail message database for access through the 
Amail system interface. The original version did not have an Amail message database. 

4. If a message has been sent to an alias for which there is no associated conventional 
mail account, the message is stored in the Amail message database. The Amail message database 
contains a repository for all messages, listing the subscriber(s) associated with the alias to which 
the message was addressed. The database contains the message (including sender, addressees, 
and ccs), date and time of transmission, and the alias of the subscriber to which the message was 
sent. The original version did not have an Amail message database. 

5. If the option was checked to send copies to other that share the alias (see above), copies 
of the message are placed in the message database for the subscribers associated with each of the 
aliases. 

Receipt of Messages- Messages sent from the Amail system can be received in a standard e-mail 
client by Amail subscribers and non-subscribers. 

Amail subscribers can also receive messages through an Amail reader interface. All 
messages received are placed in the Amail message database (see above). Since an alias can be 
associated with more than one subscriber, the Amail message database can list more than one 
subscriber as an "owner" of the message even if it was sent to only one alias. When a user logs 
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1 on and selects the option to read Amail messages (see above) the messages are rendered as an 

2 HTML page through a browser. Messages to all of the aliases associated with the user are 

3 displayed. Each message has a hotlink to respond to send & message back to the sending alias. 

4 Each message also has a link to display the background and validation information and note 

5 associated with the alias (see above). The original version did not provide an Amail viewer nor 

6 did it provide for display of validation information. 

7 Responding from off System from Amail - Individuals from off system can respond to Amail 

8 messages using the standard reply feature of their mail server. Messages will be returned to the 

9 reply address (see above). Messages received by the conventional e-mail server supporting the 

10 Amail system will forward the message to the Amail message repository for the alias listed in the 

11 return address. Responding from a standard Email client was not provided in the original 

12 version. 

13 Flip Widget 

14 Increasingly, computer applications are delivered through browsers over the Internet or an 

15 intranet. There are many design considerations in building a system for browser delivery in 

16 contrast to delivery as conventional client server application. Two related considerations are the 

17 graphic richness of a browser screen and the time lag to render a new screen. Partly because 

18 good web pages contain complex graphics and partly because the Internet can be a relatively slow 

19 network, it is important to design a web application to make few unnecessary wholesale screen 

20 changes. It is more economical from the perspective of data transmission and, hence, from 

21 response time, to create a "flat" rather than "deep" hierarchy of screens, and change only the part 

22 of a screen that is minimally necessary. 

23 For example, it is better in a data query to provide a single screen that allows a user to 

24 specify a state and city within the state than to provide a first screen for the state, followed by a 

25 second screen for the city. As the function of screens becomes more complex, however, it 

26 becomes an increasingly difficult challenge to fit all of the options onto the screen (particularly 

27 when a user selects a lower screen resolution) and while maintaining a clean appearance. The 

28 invention described here provides a tool that allows the Internet application developer to display 

29 an effectively unlimited number of options in a very small space using a very familiar and 

30 intuitive display feature. 
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1 Appearance - The "Flip Widget" tool renders a graphical object representing two rows of file 

2 folders, overlapping. The labels on the front row are visible, the labels on the second row are 

3 obscured by the front row of tabs, but the edges of the apparent back tabs are visible. The 

4 number of the apparent tabs displayed in each row is a function of the screen resolution and the 

5 length of the longest label entered by the user. 

6 The Flip Tab - In one embodiment, the rightmost tab on the front row is labeled "FLIP". When a 

7 user actuates this tab, the response is as described below. 

8 Database of labels and links - In creating the display, the application programmer enters a set of 

9 paired values. Each pair consists of (1) text of the label to be displayed and a tab, and (2) the 

10 name of an HTML link, either within or external to the page to be rendered when the tab is 

1 1 selected. 

12 Action - Upon rendering a page containing the flip widget, the two-row tab display shows the 

13 first "n" options from the list of labels and links. The value of "n" represents the maximum 

14 number that can be displayed while allowing room for the flip tab. Upon clicking any of these 

15 tabs, the corresponding link is executed. Upon clicking the flip tab, the two-row tab display is 

16 changed to reflect the next "n" options from the list of labels and links, retaining the flip tab on 

17 the right. If there are fewer than n options remaining, the flip widget will either display the last n 

18 options, or whatever number remain supplement by as many options are needed from the start of 

19 the list. Clicking the flip tab when the list has been completed starts the cycle over again with 

20 the first option. 

21 Referring to FIGS. 9 and 10, a flip widget in a first state is shown in FIG. 9. In the first 

22 state, any of the tabs A through E can be selected and the corresponding set of controls displayed. 

23 For example, in FIG. 9, tab B has been selected and the controls 430-432 are displayed. If the 

24 flip tab 410 is selected, a next row of tabs is brought forward so that the display appears as in 

25 FIG. 10 with tabs F through J showing. In FIG. 10, tab G has been selected and the 

26 corresponding controls 435-437 are displayed. 

27 FIGs. 9A and 10A show a more detailed example of how a flip widget can be used to 

28 organize functions available to a user. For example, suppose that one application is a commodity 

29 futures trading system that permits a user to execute trades, review prices, and obtain other 

30 information relating to various metals such as gold, silver, and platinum. As shown in FIG. 9A, 
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1 for example, controls or functions 430, 431, and 432 (e.g., execute a trade, review current prices, 

2 and the like) are associated with a "gold" category and can be invoked easily when that category 

3 is at the forefront of the flip widget as shown. Clicking one of the other tabs (e.g., silver tab 400) 

4 would bring the functions associated with that category to the forefront while allowing the user to 

5 readily select other categories visible behind the front. Clicking "other markets" tab 410 would 

6 change the selection of front-row tabs to a different set of categories, as shown in FIG. 10A. The 

7 "other markets" tab 410 could be continually clicked to rotate through a plurality of groupings of 

8 markets, each having a set of functions or controls associated therewith. 

9 A flip widget can be implemented in conjunction with the first or second embodiments of 

10 the present invention in order to permit many different functions to be displayed in a small screen 

1 1 space. The flip widget is a device to organize many different functions in a logical way, and can 

12 be used as a tool for building an interface to multiple applications. As one example, in a DCE 

13 (described in more detail below), there may exist n functions (e.g. bulletin boards, chat rooms, e- 

14 mail, a-mail, transaction engines, and the like) the specific availability of which can be defined 

15 by a user who creates the collaborative environment. This collection can change over time. 

16 Accordingly, the interface cannot be "hard coded" for a particular user. 

17 One way to represent an indefinite (and potentially large) number of functions in a small 

18 space is with tabs resembling a file folder, with a graphic element representing hidden cards, 

19 implying that the user can reach the functionality on the cards by paging (i.e. flipping) to them. 

20 The flip widget makes it possible to provide a link to a list of applications maintained in a 

21 database rather than requiring that they be hard coded. Programming logic for storing folder 

22 labels in a database, linking those labels with associated functions and activating them using 

23 browser-type buttons, and for performing the display features described above, are conventional 

24 and no further elaboration is necessary. Although the "flip widget" provides one method of 

25 structuring a user interface to structure a user's view of application functions, other methods can 

26 of course be used. 

27 B. DYNAMIC COLLABORATIVE ENVIRONMENT EMBODIMENT 

28 In a second embodiment of the invention, a dynamic, user-defined collaborative 

29 environment can be created in accordance with a set of tools and method steps. As explained 

30 previously, this system differs significantly from conventional networked environments in that: 
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1 (1) the environment (including access and features) is user-defined, rather than centrally defined 

2 by a system administrator; (2) each environment can be easily destroyed after completion of its 

3 intended purpose; (3) users can specify a group of participants entitled to use the environment 

4 and can define services available to those participants, including offering participation to 

5 unknown potential users; (4) the networked environment (including access features and facilities) 

6 can cross corporate and other physical boundaries; and (5) the environment offers a broad 

7 selection of tools that are oriented to communication, research, analysis, interaction, and deal- 

8 making among potential group members. Moreover, in a preferred embodiment, the environment 

9 is implemented using web browser technology, which allows functions to be provided with a 

10 minimum of programming and facilities communication over the Internet. 

1 1 FIG - 1 1 shows various method steps that can be carried out to define, create, and destroy 

12 an environment according to a second embodiment of the invention. The term "environment" as 

13 used herein refers to a group of individuals (or computers, corporations, or similar entities) and a 

14 set of functions available for use by that group when they are operating within the environment. 

15 It is of course possible for one individual to have access to more than one environment, and for 

16 the same functions to be available to different groups of people in different environments. 

17 The process of creating a collaborative environment involves the migration of tools and 

18 information resources available in the library of the environment generator into a specific 

1 9 collaborative environment. The collaborative environment can include / link to any application 

20 available to the environment generator. It can also include applications specific to the 

2 1 environment provided that theses are accessible through Internet protocols. 

22 Underlying the environment is a directory of users, information about users, and their 

23 authorities. The core structure for the environment user database should conform to a directory 

24 standard - typically DAP (Directory Access Protocol) or LDAP (the lightweight directory access 

25 protocol). The environment generator has access to its own directory of users and to the user 

26 directories of the environments it has generated. The directory of an environment can be 

27 populated initially by selecting users from the environment generator's directories. These are 

28 added to the directory of the environment in one of two ways depending on the specific 

29 implementation. Directory records can be copies from the environment generators user database 

30 to a separate database for the environment or a flag can be added to the user data record in the 
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1 environment generators users database to indicate that the user has access to the environment. 

2 The second, simple model is useful when all users in an environment have equal authority. A 

3 separate user database (directory) is necessary for an environment when the environment has its 

4 own security / authority model. 

5 Additional members can be added through a set of standard application / subscription 

6 routines. These then become known to the environment generator (as well as the specific 

7 environment) providing the foundation for greater speed and efficiency in creating subsequent 

8 environment. 

9 Beginning in step 1101, a new group is created by identifying it (i.e., giving it a name, 

10 such as "West High School Research Project," and describing it (e.g., providing a description of 

11 its purpose). The process of creating a group and defining functions to be associated with the 

12 group can be performed by a user having access to the system without the need for system 

13 administrator or other similar special privileges (e.g., file protection privileges, adding/deleting 

14 application program privileges, etc.). In this respect, environments are, according to preferred 

15 embodiments, completely user-defined according to an easy-to-use set of browser-driven user 

16 input screens. The principles described herein are thus quite different from conventional systems 

17 in which a central system administrator in a local area network can define "groups" of e-mail 

18 participants, and can install application programs such as spreadsheets, word processing 

19 packages, and the like on each computer connected to the network. Moreover, according to 

20 various preferred embodiments, the facilities provided to group members can be provided 

21 through a web-based interface, thus avoiding the need to install software packages on a user's 

22 computer. 

23 It is also contemplated that various methods of obtaining payment for creating or joining 

24 groups can be provided. For example, when a new environment or group is created, the person 

25 or entity creating the group can be charged a fixed fee with payment made by credit card or other 

26 means. Alternatively, a service fee can be imposed based on the number of members that join, 

27 the specific functions made available to the group, or a combination of these. Moreover, fees 

28 could be charged to members that join the group. The amount of the fee could also be based on 

29 the length of time that the environment exists or is used. 
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1 Although not specifically shown in FIG. 11, step 1 101 can include the step of creating a 

2 new entry in a database table (e.g., a relational or object-oriented database) to store information 

3 concerning the new group and the environment in which the group will operate. Database entries 

4 related to the group, including some or all of the information described below, can be created as 

5 the environment is defined. It is assumed that one or more computers are linked over a network 

6 as described in more detail below in order to permit the environment to be created, used, and 

7 destroyed, and that a database exists on one or more of these computers to store information 

8 concerning the environment. 

9 In step 1 102, the group members are identified. According to various embodiments, the 

10 group members can be identified in three different ways (or combinations thereof), as indicated 

11 by sub-steps 1102a, 1102b, and 1102c in FIG. 1L It is contemplated that group members can 

12 span physical networks and computer systems, such as the Internet. Consequently, group 

13 members can include employees of different corporations, government agencies, and the like. In 

14 contrast to conventional virtual private networks, both the group members and the functions 

15 made available to those group members' are entirely user-selected, thus permitting a broad range 

16 of persons to easily create, use, and destroy virtual private networks and associated functionality. 

17 First, in step 1102a, group members can be identified by selecting them from a list of 

18 known users that are to be included in the group. For example, within a corporation or similar 

19 entity, a list of internal e-mail addresses can be provided, or an electronic version of a phone list 

20 or other employee list can be provided. If the hosting computer system is associated with a 

21 school, then a list of students having accounts on the computer (or those in other schools that are 

22 known or connected to the host) can be provided. From outside a corporate entity, users can be 

23 selected based on their e-mail addresses (e.g., by specifying e-mail addresses that are accessible 

24 over the Internet or a private or virtually private network). In this step, the environment creator 

25 specifies or compels group members to belong to the group. 

26 Second, in step 1 102b, group members can be invited to join the group by composing an 

27 invitation that accomplishes that purpose. For example, a group creator may choose to send an 

28 invitation via e-mail to all members of the corporation, or all members of a particular department 

29 within the corporation, all students in a school or region, or members of a previously defined 

30 group (e.g., the accounting department, or all students in a particular teacher's class). The 
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1 invitation would typically identify the purpose of the group and provide a button, hyperlink, or 

2 other facility that allows those receiving the invitation to accept or decline participation in the 

3 group. As those invited to join the group accept participation, their responses can be stored in a 

4 database to add to those members already in the group. Invitations could have an expiration date 

5 or time after which they would no longer be accepted. As invitees join the group, the group 

6 creator can be automatically notified via e-mail of their participation. 

7 Third, in step 1 102c, group members can be solicited by way of an advertisement that is 

8 sent via e-mail, banner advertisement on a web site, or the like. Persons that see the 

9 advertisement can click on it to join the group. It is also possible for advertisements to have a 

10 time limit, such that after a predetermined time period no more responses will be accepted. The 

11 primary difference between advertising participation in a group and inviting participation in a 

12 group is that invitations are sent to known entities or groups, while advertisements are displayed 

13 to potentially unknown persons or groups. 

14 It will be appreciated that group members can be selected using combinations of steps 

15 1102a, 1102b, and 1102c. For example, some group members can be directly selected from a 

16 list, while others are solicited by way of invitation to specifically identified invitees, and yet 

17 others are solicited by way of an advertisement made available to unknown entities. 

18 In step 1 103, the functions to be made available to the group are selected. For example, 

19 the group can be provided with access to an auction transaction engine; a survey tool; research 

20 tools; newswires or news reports; publication tools; blackboard facilities; videoconferencing 

21 facilities; and bid-and-proposal packages. Further details of these facilities and tools are 

22 provided herein. The group creator selects from among these functions, preferably by way of an 

23 easy-to-use web browser interface, and these choices are stored in a database and associated with 

24 the group members. Additionally, the group creator can specify links to other web-based or 

25 network-based applications that are not included in the list by specifying a web site address, 

26 executable file location, or the like. The group creator can also define shared data libraries that 

27 will be accessible to group members. 

28 In step 1 104, the environment is created (which can include the step of generating a web 

29 page corresponding to the group and providing user interface selection facilities such as buttons, 

30 pull-down menus or the like) to permit group members to activate the functions selected for the 
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1 group. In some embodiments, access to the group may require authentication, such as a user 

2 identifier and password that acts as a gateway to a web page on which the environment is 

3 provided. Other techniques for ensuring that only group members access the group functions and 

4 shared information can also be provided. A web page can be hosted on a central computer at an 

5 address that is then broadcast to all members of the group, allowing them to easily find the 

6 environment. 

7 In step 1 105, group members collaborate and communicate with one another using the 

8 facilities and resources (e.g., shared data) available to group members. In the example provided 

9 above, for example, a group of high school students collaborating on a school research project 

10 could advertise for survey participants; conduct an on-line survey; compile the results; 

1 1 communicate the results among the group members; brainstorm about the results using various 

12 brainstorming tools; conduct a videoconference including group members at various physical 

13 locations; compile a report summarizing the results and exchange drafts of the report; and 

14 publish the report on a web site, where it could optionally be offered for sale through the use of 

15 an on-line catalog transaction engine. The group could even contact a book publisher and 

16 negotiate a contract to publish the report in book form using bid and proposal tools as described 

17 herein. 

18 In step 1 106, after the environment is no longer needed, it can be destroyed by the person 

19 or entity that created the group. Again, in contrast to conventional systems, the destruction of the 

20 environment is preferably controlled entirely by the user that created the environment, not a 

21 system administrator or other person that has special system privileges. Destruction of the 

22 environment would typically entail deleting group entries from the database so that they are no 

23 longer accessible. 

24 FIG. 12 shows one possible system architecture for implementing the steps described 

25 above. As shown in FIG. 12, an Internet Protocol-accessible web server 1201 is coupled through 

26 a firewall 1202 to the Internet 1203. The web server includes an environment generator 1201a 

27 which can comprise a computer program that generates user-defined environments as described 

28 above. Further details of this computer program are provided herein with reference to FIG. 2 1 . 

29 Web server 1201 can include an associated system administrator terminal 1204, one or 

30 more CD-ROM archives 1205 for retaining permanent copies of files; disk drives 1206 for 
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1 storing files; a database server 1207 for storing relational or object-oriented databases, including 

2 databases that define a plurality of user-controlled environments; a mail server 1208; and one or 

3 more application servers 1209 that can host application programs that implement the tools in 

4 each environment. Web server 1201 can also be coupled to an intranet 1210 using IP-compatible 

5 interfaces. Intranet 1210 can in turn be coupled to other application servers 1211 and one or 

6 more user computers 1212 from which users can create, participate in, and destroy environments 

7 as described herein, preferably using standard web browsers and IP interfaces. Web server 1201 

8 can also be coupled to other user computers 1217 through the Internet 1203; to additional 

9 application servers 1215 through another firewall 1216; and to another IP-accessible web server 

10 1213 through a firewall 1214. 

11 It will be appreciated that the system architecture shown in FIG. 12 is only one possible 

12 approach for providing a physically networked system in which user-defined network 

13 environments can be created and destroyed in accordance with the principles of the present 

14 invention. It is contemplated that application programs that provide tools used in a particular 

15 user-defined environment can be located on web server 1201, on user computers 1217, on 

16 application servers 1215, on application servers 1209, on application servers 1211, or on any 

17 other computer that provides communication facilities for communicating with web server 1201. 

18 It will also be appreciated that web pages that provide access to each user-defined environment 

19 need not physically reside on web server 1201, but could instead be hosted on any of various 

20 computers shown in FIG. 12, or elsewhere. 

21 Reference will now be made to exemplary steps and user interfaces that can be used to 

22 carry out various principles of the invention, including steps of creating a group, selecting group 

23 members, and defining functions to be made available to group members in the environment. 

24 FIGS. 13A through 13C show one possible user interface for creating a group and 

25 identifying group members. In FIG. 13 A, a user gains access to an environment creation tool by 

26 way of an authentication process. This may be a simple username and password device as shown 

27 in FIG. 13 A, or it could be some other mechanism intended to verify that the user has access to 

28 the environment creation tool. In the case of a corporation, school, or other entity that already 

29 provides a log-in procedure to access the entity's network, such log-in procedure could serve to 

30 authenticate the user for the purpose of creating a new environment. It should be appreciated that 
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1 user authentication is not essential to carrying out the inventive principles. Moreover, although it 

2 is contemplated that for ease of use (and to minimize programming) web browsers and web 

3 pages be used to receive user-defined information to create each environment, other approaches 

4 are of course possible. 

5 In FIG. 13B, the user is prompted to create a new group by supplying a group name (e.g., 

6 "Joe's Homework") and a brief description of the group. This information is preferably stored in 

7 a database file and associated with group members and functions available to those group 

8 members. 

9 In FIG. 13C, the user is prompted to identify group members. As described previously, 

10 group members are preferably identified in one of three ways (or combinations of these): (1) 

1 1 selection from a list of known group members; (2) inviting known candidates to join the group; 

12 or (3) advertising for new members. When the user clicks one of the options in FIG. 13C, he or 

13 she is prompted to supply additional information as shown in FIGS. 14A through 14C. 

14 Beginning with FIG. 14A, for example, group members can be individually specified by 

15 entering an e-mail address (e.g., an internal or external e-mail address) in a text form data entry 

16 region and/or by selecting from a previously known list. This screen permits the user to compel 

17 attendance in the group by specifying names and/or e-mail addresses to which group messages 



18 will be sent. All those added to the group in this manner will be provided with access to the 

19 environment corresponding to the group. Aliases and pre-defined groups could also be specified 

20 as the basis for membership (e.g., all those in the accounting department of a corporation, or all 

21 stents in a high school). 

22 Each member of a group might have a group email account, or they may use an off- 

23 system email account. Off-system email addresses can be maintained in a database of users. 

24 Mail sent to the group email address is preferably forwarded off-system, protecting the actual 

25 email address of the person unless that person wishes to give out that address. New members can 

26 be added until the group is completed. Although not explicitly shown in FIG. 14 A, it is 

27 contemplated that new members can be added to a previously defined group after the 

28 environment has already been created. 

29 When group members are selected or specified, the user creating the environment can 

30 also create a password for each user in the group in order to enable those in the group to access 
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1 the environment. Alternatively, when a user visits the environment, the environment can retrieve 

2 a "cookie" from the user's computer to determine whether the user is authorized to access the 

3 environment. If no cookie is available, the user could be prompted to supply certain 

4 authentication information (e.g., the company for whom he or she works, etc.) In yet another 

5 approach, authentication could occur by way of e-mail address (i.e., when the user first visits the 

6 environment, he or she is prompted to enter an e-mail address). If the e-mail address does not 

7 match one of those selected for the group, access to the environment would be denied. 

8 Turning to FIG. 14B, prospective group members can also be "invited" to join the group. 

9 The user creating the environment can specify one or more e-mail addresses to which an 

10 invitation will be sent. The invitation can be a simple text message, or it could be a more 

11 sophisticated video or audio message. An expiration date can also be associated with the 

12 invitation, such that responses to the invitation received after the date will not be accepted. 

13 Software resident in web server 1201 (FIG. 12) receives responses to the invitations and adds 

14 members to the appropriate group or drops them if the expiration date has passed or the 

15 prospective group member declines participation. Prospective members can join the group by 

16 sending a reply with a certain word in the message (e.g., "OK" or "I join"); by clicking on a 

17 button in an e-mail message; or by visiting a web site identified in the invitation. 

18 Turning to FIG. 14C, group members can also be solicited by creating an advertisement 

19 directed primarily at potential group members that are unknown. The advertisement could 

20 include, for example, a banner ad comprising text, video, and/or audio clips. The graphic should 

21 conform to the size designated for the ad on the web page. The ad could be posted on a web site 

22 by uploading the graphic through a web interface and, optionally providing a URL on the screen 

23 of FIG. 14C to link to if the advertisement is clicked. Software on the group page can render 

24 advertisements on a page either (a) every time the page is displayed, (b) in rotation with other 

25 ads; or (c) when characteristics of the user match criteria specified for the ad. 

26 The advertisement can include an expiration date after which responses would no longer 

27 be accepted. Advertisements could range from the very specific (e.g., an advertisement posted 

28 on a school's home page advertising participation in Joe's research project on drug use at the 

29 school) to more general (e.g., an advertisement that says "we're looking for minority contractors 
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1 looking to establish a long-term relationship with us" that is posted on web sites that cater to the 

2 construction industry. 

3 A qualification option can also be provided to screen prospective group members. For 

4 example, if an advertisement seeks minority contractors to participate on a particular construction 

5 project, selecting the "qualify" option would screen responses by routing them to the user that 

6 created the group (or some other authority) before the member is added to the group. Those 

7 responding to the advertisement could be notified that they did not pass the qualifications for 

8 membership in the group, or that further information is required (e.g., documents evidencing 

9 qualifications) before participation in the group will be permitted. Alternatively, an automatic 

10 qualification process can be provided to allow a prospective member to join if the person fills in 

11 certain information on the response (e.g., e-mail address, birthdate that meets certain criteria, or 

12 the like). 

13 As shown in FIG. 15, a banner ad displayed on a web site invites minority contractors to 

14 join a group that bids on information technology contracts. Those interested in the advertisement 

15 click a button, which leads them to another site (not shown) requiring that they provide certain 

16 information (qualification information, name, age, company registration information, etc.) This 

17 information is then forwarded to web server 1201 which either pre-screens the information 

18 according to pre-established criteria, or notifies the user creating the group that a prospective 

19 member has requested access to the group. In the latter case, the user could screen the applicant 

20 and grant access to the group. 

21 FIG. 16 shows one possible user interface for selecting communication tools to be made 

22 available to group members. This screen can be presented to the user creating the environment 

23 after the group has been identified and its members selected. It is contemplated that a variety of 

24 communication tools can be provided, including a bulletin board service; advertisements; white 

25 pages (e.g., a listing of members, their e-mail addresses, telephone numbers, and the like); yellow 

26 pages (e.g., a listing of services or companies represented by group members, with promotional 

27 and contact information); document security (e.g., shared access secure document storage 

28 services); anonymous e-mail (described above with respect to the first embodiment); threaded 

29 dialogs; a group newsletter creation tool; videoconferencing; and even other user-provided 
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1 applications that can be specified by name and location (e.g., URL). Details of these services are 

2 provided below. 

3 According to various preferred embodiments, dynamic collaborative environments are 

4 designed to integrate tools from multiple sources provided that they are web-accessible (i.e., they 

5 operate according to Internet Protocol and/or HTML-type standards). The categories listed above 

6 provide a reasonable taxonomy of the tools necessary for collaboration, but this list can be 

7 extended to include virtually every class of software such as computer-assisted design, 

8 engineering and financial analysis tools and models, office applications (such as word processing 

9 and spreadsheets), access to public or proprietary databases, multimedia processing and editing 

10 tools, and geographic information systems. The following describes some of the communication 

1 1 tools that can be provided: 

12 Bulletin boards . A bulletin board (see, e.g., FIG. 2) lists notices posted by group 

13 members, which may be offers to buy or sell, but need not be limited to such offers. Many types 

14 of bulletin board services are of course conventional and no further discussion is necessary in 

15 order to implement one of these services. Nevertheless, in one embodiment the following data 

16 items (attributes) can be provided for each notice appearing on the bulletin board: an item 

17 number, a title, the date posted, and one or more special attributes defined by the user. The 

18 attributes may include a field to indicate whether a listing is a "buy" or "sell " offer. The board 

19 can be provided with an integrated sorting capability. By clicking on the heading of each 

20 column, the user can sort the entries in, alternately, ascending or descending order. Thus, it is 

21 possible to organize the records from oldest to newest or newest to oldest, or to separate buy and 

22 sell offers. To limit the values on a board, a search capability can also be provided, such that 

23 only those entries that meet the search criteria are displayed. 

24 Advertisements . In a typical environment of a dynamically created network there are a 

25 number of fixed places for advertisements - the top of a page for a banner, the bottom of a page 

26 for a banner, and space on the side for small ads. The creator of the environment may choose to 

27 use none, any, or all of these spaces for advertisements. Once a space is designated for 

28 advertising, group members may place adds by completing a template that provides payment 

29 information (if required), the text for the ad (any standard image format), and a link to be 

30 executed if the ad is clicked by someone viewing the ad. 
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1 Each user is responsible for providing functionality behind the link. The ad may be 

2 displayed persistently (every time a page is displayed), in rotation with other ads for the same 

3 place, or may be triggered on the basis of user characteristics including purchasing history. 

4 Revenue can be collected for placement (fixed price regardless of how many times an ad is 

5 displayed), per time that the ad is displayed, or per click on the ad. The virtual private network 

6 provides the front-end to facilitate online placement of the ad. Display can be done by linking 

7 pages to standard ad display code, available off the shelf from several sources. This code 

8 provides for rotation of the ads. Software for customization (i.e. choosing the ad based on user 



9 characteristics) is available commercially from several sources. 

10 White pages. White pages provide a comprehensive listing or directory of members with 

11 information about them and information regarding how to contact them. Various types of 

12 commercially available software can be used to manage such directories, and it is elementary to 

13 code typical directories that have fixed contents for each member. 

14 A web-accessible directory can be used in accordance with various embodiments of the 

15 invention. One type of directory that can be provided differs from directories having fixed 

16 structures. The key differences are as follows: 

17 (a) User control over information Users enter and maintain their own information 

18 directly, rather than through a central organization. This provides more immediate update of 

19 data and reduces transcription errors. It makes it simple, for example, for people to change their 

20 phone number when they are temporarily working at another location. 

21 (b) Multiple points for quality control. The data regarding each user can be displayed to 

22 the user periodically (e.g.30, 60, and 90 days), and the user prompted to update and verify the 

23 data. A feedback capability can be provided for members of a group to report errors they find. 

24 Email addresses can be "pinged" periodically to determine if they still exist. In addition, server 

25 management staff can periodically review accounts that have had recent activity. 

26 (c) Object structure. A directory entry consists of a collection of data elements. These 

27 elements include such things as name for addressing (Dr. John D. Smith), sort name (Smith, John 

28 D), or primary work telephone (800-555-1212). Traditional mail systems have a fixed number 

29 of rigidly formatted elements. In one embodiment, a more flexible approach can be used in that 

30 individuals identify which elements they wish to add to the collection comprising their directory 
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1 entry. For example, a person can add 3 , 4, 5 or more telephone numbers attaching a note to each 

2 explaining its use (e.g. "for emergencies after 8PM"). 

3 (d) Direct link to communications tools. Where a directory refers to a contact method 

4 (e.g. a telephone number), the method can be invoked directly from an entry if the necessary 

5 software is available. For example, phone number can be dialed, email messages initiated, or a 

6 word processing session initiated with letter and envelope templates, preloaded with address 

7 information. 

8 (e) Descriptive information. In addition to contact information, each directory can 

9 contain information describing the entry (individual or business). The description can be 

10 different in each group or it can be the same. The descriptive is free form, with the exception 

11 that the user may drop in terms from a group-specific lexicon. This lexicon can include terms 

12 specific to the industry (e.g. "fuel system") for the automotive industry, or preferred forms of 

13 standard terms (e.g. "California" rather than "CA", "Ca", or "Calif."). Standardization of terms 

14 in this way makes search the directory more reliable. 

15 Yellow pages . Conventional "yellow pages" products provide a one level classification 

16 of directory entries designed to facilitate identification of and access to an individual or 

17 organization with specific interests and capabilities. Within industries, and particularly online, 

18 multi-level hierarchical directories are common, with the multiple levels providing more precise 

19 classification. There are numerous commercial products for maintaining online yellow page 

20 type classification systems. 

21 Any web-accessible directory can be connected to a DVPN group. A preferred method 

22 offered with the system integrates the classification system with the descriptive field in a 

23 directory entry. Every time a standard term pertaining to a classification is pulled from the 

24 lexicon, the entry is added to that classification in the hierarchical sort. In addition to 

25 hierarchical access, this correspondence between the traditional hierarchical sort and the free- 

26 form description with standardized terms makes it possible to access records via search rather 

27 than browsing the hierarchy. Searching makes it possible to identify an organization with 

28 multiple capabilities (e.g. "brake repair" and "frame straightening"). This search capability is 

29 much like a general web-search using a tool like AltaVista's or Inktomi' s search engine and can 

30 use the same search engine, but differs in that material being search is in a precisely defined 
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1 domain (group members), the information being searched is limited and highly quality controlled 

2 (i.e. group directory entries), and has a precision rooted in a precise vocabulary (the lexicon used 

3 in preparing the description). 

4 Document repository . Any commercial web-enabled document repository can be 

5 integrated into a group. Examples are Documentum and PC DOCs. An improved version 

6 offered specifically with the DVPN package was described above. 

7 Document security. Within the document repository various tools can be provided to 

8 protect the security of documents. These include (1) limiting access to a document to certain 

9 people or groups; (2) only displaying the directory entry for documents to people who can access 

10 it; (3) password protection; (4) encryption; (5) secure archive in read only mode on a third-party 

1 1 machine; (6) time-limited access and (7) a secure hash calculation. 

12 All of the above are conventional except for time-limited access and the secure hash 

13 calculation. Software for limiting access to a document to a certain period is available from 



14 Intertrust, among others. A secure hash is a number that is characteristic of the document 

15 calculated according to a precisely defined mathematical algorithm. There are several secure 

16 hash algorithms, and implementers can develop their won. They are "trap door" in nature. That 

17 is, the calculation can be performed with reasonable effort, but the inverse of the function is 

18 computationally intractable. The classic example of a trap door function is multiplication of 

19 very large prime number (on the scale of hundreds of digits). The product can be calculated with 

20 relative ease, but factoring the product (the inverse function) is very time consuming, making if 

21 effectively impossible with generally available hardware. This method is used in public key 



22 encryption, but can be applied equally well in secure hash, though other trap door functions are 

23 preferred, in particular, the one specified by the U.S. Department of Commerce as FIPS standard 

24 180. Code to implement this standard can be developed from published algorithms. 

25 Anonymous e-mail (described above with respect to the first embodiment); 

26 Threaded dialogs . Threaded dialogs are a collection of messages addressing a specific 

27 topic, added serially, not in real time. They are threaded in the sense that new topics can branch 

28 off from a single topic, and topics can merge. According to one embodiment, threaded dialogs 

29 differ from conventional news group functionality in that (1) users can initiate new topics; (2) 

30 users can post a message to one topic, then indicate that the message pertains to other topic as 
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1 well; (3) browsers reading a message may continue down the original thread or one of the 

2 alternates if other topics are suggested. 

3 Group newsletter creation tool , A newsletter creation tool can be used to link columns 

4 provided by multiple users (and maintained as separate web documents) into a whole through an 

5 integrating outline maintained by an "editor". The purpose of the tool is to provide the look and 

6 feel of an attractive single document to a disparate collection. To create the newsletter the editor 

7 generates an outline identifying an author for each component and a layout. Art for the first 

8 page can be provided. Through messaging, the authors are provided a link to upload their 

9 content. Content is templated to include a title, date, a by line, one or more graphic elements, a 

10 summary for the index, and text. The editor may allow documents to go directly to "publication" 

1 1 or require impose a review and editing step. 

12 Chat groups . Real time chat room software is widely available from many sources 

13 including freeware and shareware. 

14 Audio and videoconferencing . Commercially available tools for web-based audio and 

15 video conferencing can be included in the group functionality. Examples are Net Meeting and 

16 Picture Tel software. 

17 FIG. 17 shows one possible user interface for selecting research tools to be made 

18 available to group members. As shown in FIG. 17, various tools such as a mortgage calculator, 

19 LEXIS/NEXIS access, news services, Valueline, and other research tools can be provided by 

20 checking the appropriate box on the display. All of these research tools are conventional and 

21 commercially available (via web-based links and the like). 

22 FIG. 18 shows one possible user interface for selecting transaction engines to be made 



23 available to group members. As shown in FIG. 18, many different types of transaction engines 

24 can be provided to group members, including electronic data interchange (EDI) ordering; online 

25 catalog ordering; various types of auctions; sealed bids; bid and proposal tools; two-party 

26 negotiated contracts; brain writing (moderated online discussion) and online Delphi 

27 (collaborative estimation of a numerical parameter). The following describes various types of 

28 transaction engines in more detail. Enhanced features (i.e., those that differ from conventional 

29 products) are highlighted in gray text. 
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1 A. Order placement (online catalog) transaction engine 

2 An order placement or online catalog engine allows the buyer to place an order for a 

3 quantity of items at a stated fixed price, essentially ordering from an online catalog. The catalog 

4 contains the description and specification of the offerings. The catalog may be publicly 

5 accessible (Subtype la) or provided for a specific customer (Subtype lb). Prices are included in 

6 the catalog but may be customer specific, may vary with quantity purchased, terms of delivery 

7 and performance (e.g. cheaper if not required immediately). The catalog can represent a single 

8 company's offering or an aggregate of the offerings from several companies. The catalog can 

9 range from a sales-oriented web site designed for viewing by customers, to a engine designed 

10 only accept orders sent via electronic data interchange (EDI). Note that the catalog can be 

1 1 shopper oriented (i.e. designed to sell) or a simple, machine-readable list of available items and 

12 prices. The following describes in more detail steps that can be executed to create an online 

13 catalog: 

14 1 . Enter and maintain a framework for catalog 

15 1.1. Enter / delete / edit categories. Categories are titles for groups of items, such as 

16 "furniture" or "solvents" 

17 1.2. Enter / delete / edit subcategories. Subcategories are categories within categories, 

1 8 effectively establishing a hierarchy of products. Example: furniture/dining room/tables. 

19 1.3. Create groups of categories and subcategories (e.g. "see also...."). The grouping allows 

20 a person browsing items to be referred to another category that may contains items of 

21 interest. For example, someone may reach the furniture/dining room/tables and then be 

22 referred to furniture/office/conference room tables where other suitable tables may be 

23 listed, or to furniture/dining room/chairs to buy chairs that make the table. This cross- 

24 referencing transforms the hierarchical arrangement of categories into a web. 

25 2. Enter / edit / delete items in catalog by entering and updating the information listed below. 

26 The system allows users to enter this information and provides basic quality assurance. 

27 2.1. Catalog item number 

28 2.2. Supplier part number(s) 

29 2.3. Name of item 

30 2.4. Description 
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1 2.5. Photos and drawings 

2 2.6. Specifications (depends on item type). Different items have different specifications. 

3 For example, a computer printer can have color vs. black and white, dots per inch 

4 resolution, paper size, etc. In contrast to a fixed, hard coded catalog, the 

5 specification section of the general purpose catalog engine the user prepares the 

6 specification section by selecting parameters from a list and then specifying a value 

7 for that parameter. The parameter list contains values such as length, width, height, 

8 voltage, color, resolution etc. It is can be extended by the manager of the auction 

9 environment. A lister selects a necessary parameter (e.g. length, then enter the value, 

10 such as 14")- The specification section is a concatenation of individual specifications. 

11 2.7. First available date 

12 2.8. Last available date 

13 2.9. Category (categories) into which the item fits 

14 2. 10. Alternate suggestion(s) if product not available 

15 2. 1 1 . Related and associated products (e.g. printer supplies for a printer or other household 

16 items with the same pattern. 

17 2. 12. Additional information at the option of the individual or organization listing the item. 

18 3 . Enter / update pricing information 

19 3.1. Simple price. The fixed prices is per item or per unit. The price must specify the 

20 3.2. Pricing algorithm — link to code for pricing algorithm 

21 4. Take Orders 

22 There are two variants: 4a: manual purchase in which a person browses a catalog and selects 

23 and item for purchase and 4b: automated order in which a purchase is initiated by an 

24 electronic message. 

25 Variant 4a: Manual Purchase 

26 4.1. Potential buyers access the catalog by drilling down through the category / subcategory 

27 tree or 

28 4.2. Buyers search fields in catalog to identify the appropriate item. The search may examine 

29 the title, description, or any of the specification fields. 

30 4.3. Display general information for item(s) meetings specifications 
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1 4.4. Allow user to modify search or to select specific item if the items displayed to do not 

2 meet his requirements 

3 4.5. Display detailed information for selected item 

4 4.6. Display the fixed price or calculate price if prices is based on an algorithm. The pricing 

5 algorithm may include parameter such as characteristics or affiliation of the users (e.g. 

6 affiliated with a pre-negotiated discount program) , delivery date and mode, and quantity. 

7 4.7. Offer the option to purchase or search again if they choose not to purchase. 

8 4.8. If the buyer opts to proceed with the purchase, then check the availability of the item by 

9 linking to the sellers inventory system 

10 4.8.1. If the item is available then execute an 'add to basket'. That is, place it on a list 

1 1 of items designated for purchase. 

12 4.8.2. If the item is not available, then execute the contingent response: 

13 4.8.2.1. Offer delivery at predicted date 

14 4.8.2.2. Terminate the sale, but offer to deliver or notify when next the item is next 

15 available. 

16 4.8.2.3. Suggest alternate items 

17 4.8.2.4. Report 'sorry' and abort transaction 

18 4.9. Offer option to purchase addition options 

19 4.9. 1 . If offer is accepted, execute from step 4. 1 

20 4.9.2. If offer is not accepted, proceed with step 4.10 

21 4.10. Conclude the transaction 

22 4.10.1. Collect shipping information, offer options 

23 4. 10.2. Collect payment information 

24 4.10.3. Validate payment 

25 4.10.4. Summarize order 

26 4. 10.5. Obtain final authorization 

27 4. 10.6. Generate receipt 

28 Variant 4b: automated order, done using an EDI (electronic data interchange) message 

29 4. 1 Accept requests for item 

30 4.2 Return price and confirmation of availability 
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1 Note that users may conduct transactions without employing EDI. It is possible, however, 

2 for members to agree on a transaction EDI format either by completing a template within the 

3 system or selecting a pre-established EDI format from a library. This library can include formats 

4 developed by recognized standards organizations (e.g. UNEDDFACT or ANSI) or formats 

5 developed specifically for an industry or a trading environment. Once there is agreement on a 

6 format, transactions can be initiated, concluded, and confirmed through the exchange of 

7 appropriate EDI messages. As many commercial ordering, accounts payable, accounts 

8 receivable and enterprise resource planning systems have an EDI interface the collaborative 

9 environment should have the capability to forward the message to the order fulfillment system. 

10 B. English Auction Transaction Engine 

11 In an English Auction, a single item is offered for sale to many buyers. The auction can 

12 be open or limited to pre-qualified bidders. The buyers offer bids in turn, each succeeding all 

13 prior bids. The highest bid received at any point in the auction is visible to all buyers. The 

14 identity of the highest bidder may or may not be visible to traders. Buyers may increase their 

15 bids in response to this information. Award is to the highest bidder at the end of trading. The 

16 end of trading is reached when there are no higher bids during an interval that may be formally 

17 defined or determined by the manager of the auction at the time of execution. 



18 There are two models for the access to the transactions. In the first model, all buyers and 

19 sellers are members of the group. In the second model, all sellers are members of the group, but 

20 buyers can include members and non-members. If non-members are allowed to buy, the creator 

21 the transaction must enter a new URL for buyers. This is a sub-URL of the main group URL. A 

22 registration process may be established for the buyer URL. 

23 In live auctions (as opposed to online) all traders are connected at the same time, and the 



24 duration of the auction is brief - typically only a few minutes. In online trading, it is not 

25 necessary for all of the bidders to be present (i.e. connected at the same time). To distinguish 

26 between these two options they are designated (a) concurrent (everyone bidding at the same time) 

27 and (b) batch (not everyone connected simultaneously. The manager of the auction can set the 

28 minimum bid and the minimum increment. 

29 1. The first step in conducting an auction is to collect information on the items being offered for 

30 sale. This is done online. The information collected includes: 
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1 1.1. Identity of seller. Note that the business rules of the auction may require advance 

2 registration of sellers to verify their identity. 

3 1.2. Descriptions, optionally including attachments' and photographs, independent 

4 certifications or appraisals, and anything else in digital form necessary or useful in 

5 determining the value of the item. 

6 1.3. Reserve price 

7 1 .4. Minimum increment 

8 1.5. Time offered for sale 

9 1 .6. Time bidding is scheduled to end 

10 1.7. Verify the seller's consent to the rules of the auction house regarding delivery, payment, 

1 1 responsibility for non payment, etc. 

12 2. If the business rule of the auction house is to require payment up front, collect payment either 

13 by: 

14 2. 1 . Debiting a deposit account 

15 2.2. Charging to account for billing 

16 2.3. Collecting online payment such as through a credit card. 

17 3. Post information about auction, including: 

18 3.1. Description of items to be auction 

19 3.2. Auctions rules: 

20 3.2.1. Qualification process for bidders 

21 3.2.2. Time of bidding 

22 3.2.3. Criterion for ending bidding - time between bids 

23 3.2.4. Legal statement - responsibilities of buyer and seller, limitation of liability 

24 4. Execute qualification process (optional) 

25 4.1. Admit bidders who are qualified based on past participation 

26 4.2. Provide fill-in-the blank qualification form new bidders 

27 4.3. Collect information 

28 4.4. Conduct automated review or manual review 

29 4.5. Inform prospective bidder of qualification or not 

30 Variant (a): concurrent auction 
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1 5. Conduct Auction 

2 5.1. Fifteen minutes prior to appointed time for auction, display "Welcome" screen with 

3 space for qualified bidder to enter an alias or handle to be used in the auction. Screen 

4 should have a description of the object. Show time until auction starts. Auto refresh at 

5 15 second intervals. 

6 5.2. At appointed time, display the main auction page with the following information: 

7 5.2.1. Description / picture of item for auction stored in a separate, static frame of the 

8 PC so that it does not need to be downloaded each cycle. 

9 5.2.2. Current bid (initially the reserve price) 

10 5.2.3. Suggested next bid (e.g. current + 3 * increment) 

1 1 5.2.4. Button to accept suggested next bid 

12 5.2.5. Field to enter bid higher than suggested next 

13 5.2.6. Handle of the highest bidder 

14 5.3. Refresh main auction page at 15 second intervals 

15 5.4. Collect bids, either 

16 5.4. 1 . Notice that the suggested bid was accepted 

17 5.4.2. Bid higher than accepted bid 

18 5.4.3. If new bid is lower than current highest, disgard 

19 5.4.4. If higher than current highest then 

20 5.4.4. 1 . Log identity of highest bidder 

21 5.4.4.2. Update highest bid 

22 5.4.4.3. Update next suggested bid 

23 6. If nobody accepts the suggested bid, then 

24 6. 1 . Reduce suggested next bid 

25 6.2. If accepted, resume normal sequence 

26 6.3. If not accepted, reduce suggested next bid 

27 6.4. If accepted, resume normal sequence 

28 6.5. If not, begin close 

29 6.6. "Going once . . if response, resume normal sequence, else 

30 6.7. "Going twice . . if response, resume normal sequence, else 
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1 6.8. Done. Display closing screen 

2 7. Settle with winning bidder, two models 

3 7. L Connect buyer to seller for direct settlement 

4 7.2. Collect money from buyer, deduct fee, convey amount to seller 

5 Variant (b): batch (i.e. time limited) auction 

6 Conventional on-line batch (time limited) auctions are common. E-bay is the most 

7 prominent example. This process description continues from step 4 of the English auction 

8 description as the startup of the concurrent and batch auctions are the same. 

9 5. Conduct auction: Until closing time for an item: 

10 5. 1 . On entry to system display the following for the potential buyer: 

11 5.1.1. Latest listing 

12 5.1.2. Categories 

13 5.13. Search screen 

14 5.2. On selection of categories: 

15 5.2. 1 . Execute dill down 

16 5.2.2. Retrieve count of items that meet criteria 

17 5.2.3. If more count is less than 25 (or other small number (n) consistent with the 

18 layout of the screen) retrieve all items that meet criterion 

19 5.2.4. If count is more than n, retrieve n auctions with nearest expiration time 

20 5.2.5. Display link list to all items in list, sort order should be auction with 

21 nearest deadline to most distant 

22 5.2.5.1. Item name 

23 5.2.5.2. Time till end of auction 

24 5.2.5.3. Highest current bid 

25 5.2.6. On user selection of the item, display same information as above plus 

26 5.2.6.1. Description 

27 5.2.6.2. Photo (if any) 

28 5.2.6.3. Attachments (if any) 

29 5.2.7. If count is more than n, display further drill-down options as well as item 

30 , information above 
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1 5.3. Accept new bid through the display screen 

2 5.3. 1 . Log bids in order, reject if bid is not higher than last high bid by increment. 

3 5.3.2. If bid is rejected, tell bidder that their bid is not sufficient 

4 5.3.3. Update database recording highest bid, bidder, time of bid 

5 5.3.4. Display screen to user to confirm that their bid is the highest 

6 6. When the time limit is reached, determine if a new bid has been received in the last 3 minutes 

7 (or other short time period). If so, extent the bidding time by 3 minutes (or other short time 

8 period) and execute step 5 with a new closing time. 

9 7. When the time limit is reached, including all extensions under step 6, then 

10 7. 1 . Email message to highest bidder that they won 

1 1 7.2. Add transaction to completed deals 

12 7.3. Update splash and add screens 

13 7.4. Settle with winning bidder- two models: 

14 7.4. 1 . Connect buyer to seller for direct settlement 

15 7.4.2. Collect money from buyer, deduct fee, convey amount to seller 

16 C. Dutch Auction Transaction Engine 

17 A Dutch auction, like a standard auction, involves the sale of a single item or batch with 

18 fixed specifications. There is one seller, and many potential buyers. The seller sets the prices, 

19 ideally higher than any buyer's maximum bid price. The offered price is reduced by a fixed 

20 increment at fixed intervals until a buyer accepts the price. The purchase goes to the first buyer 

21 in to accept the price. In the physical world (as opposed to the online world), Dutch auctions are 

22 rarely if ever run concurrently. In a live trading room, it could be difficult to determine which 

23 buyers was first to commit to a price when several are willing to pay the same amount. The 

24 Dutch auction is relatively simple to implement in an electronic environment. There are, at 

25 present, no online Ducth Auctions of which the inventors are aware. 

26 1 . Enter and maintain a framework for catalog 

27 1.1. Enter / delete / edit categories. Categories are titles for groups of items, such as 

28 "furniture" or "solvents" 

29 1.2. Enter / delete / edit subcategories. Subcategories are categories within categories, 

30 effectively establishing a hierarchy of products. Example: furniture/dining room/tables. 
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1 1.3. Create groups of categories and subcategories (e.g. see also....). The grouping allows a 
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listed, or to furniture/dining room/chairs to buy chairs that make the table. This cross 
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referencing makes transforms the hierarchical arrangement of categories into a web. 
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z. 


Execute qualification process (optional) 
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2.1. Admit bidders who are qualified based on past participation 
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2.2. Provide till-in-the blank qualification rorm new bidders 
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2.3. Collect information 
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2.4. Conduct automated review or manual review 
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2.5. Inform prospective bidder of qualification or not 


13 


3. 


Collect information on items to be auctioned and owners, including 
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3.1. Identity ol seller 
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3.2. Descriptions, optionally including attachments and photographs, independent 
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certifications or appraisals, or other information necessary to establish the value of the 
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tiem 
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3.3. Categorization 
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3.4. Starting price 
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3.5. Increment, Interval for reduction 
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3.6. Minimum price 
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3.7. Obtain consent to rules (possibly as part of registration/qualification process) 
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3.8. Collect to conduct auction if item is 
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3.9. Calculate time to take item off auction by determining the number of steps (intervals) 


25 




necessary to reduce price from the starting price to the minimum 


26 




3.10. Record all of the above information in the Dutch auction database 


27 


4. 


Cull expired options 
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4.1. Search database periodically for items where current time is later than time to take item 
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off auction (2.9) 
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4.2. Inform owner that item was not sold 
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1 4.3. Delete entry from database 

2 4.4. Prompt for revised terms start of another auction, create new entry if user takes option 

3 5. When the buyer enters the system display a list of high level categories, a prompt for search 

4 criteria, and/or a link to a search page. Allow user to drill down through categories or enter 

5 search parameters. 

6 5.1. Retrieve count of items that meet criteria 

7 5.2. If more count is less than 25 (or other small number (n) consistent with the layout of the 

8 screen) retrieve all items that meet criterion 

9 5.3. If count is more than n, retrieve n auctions with nearest expiration time 

10 5.4. Display link list to all items in list, sort order should be auction with nearest deadline to 

1 1 most distant 

12 5.4.1. Item name 

13 5.4.2. Time till end of auction 

14 5.4.3. Current price: 

15 5.4.3. 1 . Retrieve starting price (SP) and increment (1$) 

16 5.4.3.2. Calculate number of intervals since start of auction (INT) 

17 5.4.3.3. Determine price = SP - (INT * $) 

18 5.5. On click, display same information as above plus 

19 5.6. Description 

20 5.7. Photo (if any) 

21 5.8. Attachments (if any) 

22 5.9. The display screen should include a button that allows the buyer to purchase the item at t 

23 the selected price. 

24 6. When the user clicks the "buy" button 

25 6.1. Email message to highest bidder that they won 

26 6.2. Add transaction to completed deals database 

27 6.3. Settle with winning bidder— two models: 

28 6.3.1. Connect buyer to seller for direct settlement 

29 6.3.2. Collect money from buyer, deduct fee if any for auction and payment 

30 services, convey the remainder to seller. 
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1 D. Reverse English Auction Transaction Engine 

2 In a reverse auction, there are multiple buyers to one seller. Prices come down rather 

3 than up. There are many variants of a reverse auction. The variant discussed here is a reverse 

4 English auction. Reverse auctions have been implemented on line in Open Markets. 

5 The process for posting an item for bid and for qualifying bidders is the same as for other 

6 auctions. The difference here is that the buyer may optionally set a maximum price. 

7 1 . Accessing the list of items sought 

8 Potential bidders access items sought by working through a hierarchy of categories and 

9 subcategories or entering search criteria, as for other auctions. A list of items within the 

10 category/subcategory and/or meeting the search criteria is displayed. The user may then 

11 1.1. Terminate the session on finding no suitable items 

12 1 .2. Revise the search criteria 

13 1 .3. Select an item on which to bid 

14 2. If the user selects an item on which that may wish to bid, detailed information about the items 

15 is displayed. This item may include the following information: 

16 2.1. Name 

17 2.2. Seller 

18 2.3. Description 

19 2.4. Detailed specifications for items 

20 2.5. Delivery requirements 

21 2.6. Proposed terms 

22 2.7. Current low bid 

23 3. If the user determines that they should bid, he accesses the bid entry screen from the detailed 

24 description in Step 2 above. Making a bid consists of entering the following information: 

25 3. 1 . New, lower bid 

26 3.2. Comments pertaining to any special terms, features, or conditions 

27 3.3. Attachments containing relevant additional information and any certifications required 

28 by the buyer 

29 4. On receipt of bid, there are two options - either all bids are accepted, or bids are accepted 

30 only after review of information by the buyer. 
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1 4.1. Case 1: all bids are accepted 

2 4.1.1. New bid is checked to determine if it is lower than prior bid 

3 4.1.2. If so, then 

4 4. 1.2. 1 . bidder is notified that their bid is currently the lowest 

5 4. 1 .2.2. seller is notified of new low bid 

6 4. 1 .2.3. bid database is updated 

7 4.1.3. If not, then 

8 4. 1.3. 1. Bidder is notified that their bid is not the lowest 

9 4. 1 .3.2. Bid screen is displayed so that bidder may lower bid 

10 4.2. Case 2: bids are accepted after review by buyer 

1 1 4.2. 1 . Buyer is notified of bid via email or online message 

12 4.2.2. Buyer accesses complete information on the proposed bid through the system 

13 4.2.3. Buyer select accept bid or reject bid. 

14 4.2.4. If bid is accepted, then 

15 4.2.4. 1 . Bidder is notified that their bid is currently the lowest 

16 4.2.4.2. Bid database is updated 

17 4.2.5. If bid is not accepted, then 

1 8 4.2.5. 1 . Buyer enters reason for not accepting bid 

19 4.2.5.2. Bidder is informed that bid is rejected with reason stated above 

20 4.2.5.3. Bidder may access the bid screen to revise offer 

21 5. When time period has expired and there have been no bids within a short specified interval, 

22 then 

23 5. 1 . If at least one bid less than the maximum has been received, then: 

24 5.1.1. Notify low bidder that their offer was successful 

25 5.1.2. Add transaction to completed deals database 

26 5.1.3. Settle with winning bidder- two models: 

27 5.1.3.1. Connect or introduce buyer to seller for direct settlement 

28 5.1.3.2. Collect money from buyer, deduct fee if any for auction and payment 

29 services, and convey the remainder to seller. 

30 . 5.2. If no bid less than the maximum has been received, the 
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1 5.2.1. Notify buyer 

2 5.2.2. Allow buyer to revise bid criteria 

3 E. Sealed Bid Transaction Engine 

4 In a sealed bid system, the buyer publishes or distributes detailed, fixed specification to a 



5 number of potential bidders (who may or may not be prequalified). Bidders submit binding bids 

6 by a specified deadline, in a specific format that allows ready comparison. The competitive 

7 bidding process is distinguished from the bid and proposal process by the complexity of the 

8 specifications and the bids. In a simple competitive bid, competition among the bidders is along 



9 one or two readily quantified dimensions (always including price) and there is little or no room 

10 for variation in the form or specifications of the offering. Comparison of the bids is elementary. 

1 1 The process for posting an item for bid and for qualifying bidders is the same as for other 

12 transactions as is the method to identify items on which to bid either using the hierarchy of 

13 categories and subcategories or a search engine. 

14 1. If the user selects an item on which he may wish to bid, detailed information about the items 

15 is displayed. This item may include the following information: 

16 1.1. Name 

17 1.2. Seller 

18 1.3. Description 

19 1.4. Detailed specifications for items including all information necessary to prepare a bid 

20 1.5. Bid instruction including specification for any documentation the buyer may required 

21 with a bid (e.g. proof of bonding or license) 

22 1.6. Notice of any fees for bid registration 

23 1.7. Delivery requirements 

24 1.8. Proposed terms 

25 2. After review of the bid requirements, the user may choose not to bid or may enter a bid. The 

26 process for entering a bid consists of preparing a bid package, including the price offered and 

27 any necessary supporting documentation. This is done by completing an online form, with 

28 provision for attachments. The bid is submitted through the system where it goes into a 

29 database of bids that are not opened to the closing time for the bidding process. 

30 3. At the closing time, all bid packages are conveyed to the buyer. 
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1 3. 1. If there are no bids, the buyer is offered the opportunity to revise the request for bids. 

2 3.2. If there are multiple bids, the buyer reviews the bids and selects the lowest priced 

3 qualifying bid. They buyer informs the seller and arranges payment and delivery in 

4 accord with the terms stated in the bid package. 

5 F. Order Matching Transaction Engine 

6 In an order-matching system there are many potential buyers. Each posts binding offer to 



7 buy (bid amount) or sell (asked amount). The process proceeds in real time. The order 

8 matching system constantly compares bid and asked and, when a match is found within a 

9 specified spread, the deal is concluded. No accepted offer can be repudiated, but offers may be 

10 withdrawn before a deal is consummated. The strike price is posted so that buyers and sellers 

11 can modify their offerings in real time. The items traded are fungible so that price is the only 

12 decision. For the market to operate efficiently the items traded must be tightly defined and the 



13 terms of sale must be fixed and determined in advance. This is typically done by the operation 

14 or an exchange, with the order-matching engine operating in the background. To insure that the 

15 items traded are well defined, and the terms of sale are rigid example of an order matching 

16 process in stock trading on an exchange. 

17 Users of an order-matching engine are all potential buyers and seller. They are qualified 

18 in advance using a process like that outlined by for auction with the extension that deposit 

19 accounts are frequently required given the speed of transactions in exchange environments. 

20 1. Establish and maintain items to be traded. All functions in this category are reserved to the 

21 manager of the exchange or a designee. 

22 To add (i.e. "list" and idem), enter 

23 1.1. Unique item number or symbol 

24 1 .2. Description of item (e.g. Sears Class A Common Stock) 

25 1.3. Terms and conditions ownership (e.g. who can own) if any 

26 1.4. Trading units (e.g. shares, blocks, etc.) 

27 1 .5. Additional information as required by the rules of the exchange 

28 To delete (i.e. "delist'* and item) 

29 1 .6. Select the item to be deleted 

30 L7. Confirm deletion 
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1 2. On entry to the system, potential buyers and sellers can review the price of the last transaction 

2 of any item, either through a list or a search by item name or symbol. The current highest 

3 asked and lowest bid price are also shown. 

4 3. An offer to sell is posted by entering the following information: 

5 3.1. Item number or symbol 

6 3.2. Quantity offered 

7 3.3. Proposed price ("asked") 

8 3.4. Seller 

9 3.5. Offers may be revise at any time prior to consummation of a deal 

10 4. An offer to buy is posted by entering the following information 

11 4.1. Item number or symbol 

12 4.2. Quantity offered 

13 4.3. Proposed price ("asked") 

14 4.4. Buyer 

15 4.5. Offers may be revised at any time prior to consummation of a deal 

16 5. Offers to buy and sell are constantly reviewed by the software. When there is an offer to buy 

17 and sell at a price within a preset difference. When prices match, buyers and sellers are 

18 notified of the transaction, and the transaction is recorded. The display of the last transaction 

19 price, the highest bid and the lowest asked price is updated. 

20 6. The transaction is conveyed to the backend accounting system of the exchange. 

21 G. Bid and Proposal 

22 The bid and proposal process is typically used for procurement of large or complex 

23 products or services, in which cost is not the only factor. Cost must be weighed against the 

24 buyer's assessment of the quality and suitability of an offering and the ability of the bidder to 

25 deliver the product or perform the specified services. The bid and proposal process is 

26 conducted between one buyer (possibly representing a consortium) and many potential sellers, 

27 sometimes organized into teams. The buyer issues specifications that may be general or highly 

28 specific, brief or very lengthy. The specifications may be distributed freely or to a list of 

29 qualified buyers. 
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1 With physical RFPs, the size and the associated cost of distribution make it common 

2 practice to advertise the availability of the RFP first, sending copies only to those that request it. 

3 Frequently, the requestors are required to supply information to establish their qualifications to 

4 bid. While cost is not an issue in electronic dissemination of RFPs, the model of advertising 

5 prior to distribution is still useful in managing the qualification process. This is addressed as 

6 variant (a) is this description. Variant (b) requires no prequalification. 

7 In a competitive bid on fixed requirements (sealed bid or auction), there is typically very 

8 little communication between buyer and seller between publication of the request and submission 

9 of the bids. The requirements are comparatively simple, clear, and unambiguous. In contrast, 

10 the bid and proposal process may involve considerable communication between buyer and seller. 

1 1 The process may begin with a bidders' conference to answer questions about the requirements. 

12 Additional questions from bidders may be accepted, though not all need be answered. 

13 Questions and answers may be made available to all bidders or the response may be in private. 

14 This dialog is crucial for two reasons. First, it helps the bidders understand the requirements and 

15 to be responsive in their bids. Second, it is not unusual for the bidders' questions to identify 

16 some point of ambiguity, error, or contradiction in the specifications, leading to a modification of 

17 the RFP. The diverse perspectives of the bidders, and the close attention required on their part 

18 to prepare a bid inherently provides an excellent review of the RFP. 

19 The initial phase of the RFP process concludes with submission of the bids, but this is far 

20 from the conclusion of the process. Commonly, questions arise from the review of the 

21 proposals. These may relate to a specific submission or have broader implications, leading to 

22 modification of the requirements. The list of bidders can be culled to the best candidates. 

23 These are asked to answer questions about their proposals and to provide additional and 

24 clarifying information. 

25 The process described here is built around the document repository described elsewhere 

26 in this application. Through this process of refinement, the list of bidders is narrowed to one or 

27 two with whom a contract is negotiated. The process of negotiation is addressed as a separate 

28 transaction type (Negotiation Engine) as it may be conducted without the bid and proposal 

29 process. 

30 Variant (A): with pre-qualification 
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1 1. Software supports the user in creating a web site for the proposal process. Initially this site 

2 manages the process for requesting the request for proposal (RFP), qualifying bidders, and 

3 disseminating the RFP. 

4 2. Supported by the system software, the bidder creates and RFP advertisement by 

5 2.1. entering a summary of the RFP. 

6 2.2. entering a summary of the information needed to qualify as a bidder or 

7 2.3. attaching a form (HTML web page or template for paper form) for entering qualifying 

8 information 

9 3. The RFP advertisement includes file transfer software for uploading qualifying information 

10 to the repository. 

1 1 4. Disseminate RFP advertising 

12 4. 1 . Post on public bulletin board or 

13 4.2. Disseminate via mail to selected users 

14 5. When users access the system, issue them an encryption key and PIN to be used for 

15 subsequent uploads and communications to verify their identity. 

16 6. Receive requests for RFP in repository 

17 6.1. Prompt for key 

18 6.2. Encrypt submission 

19 6.3. Upload 

20 6.4. Generate receipt - should include an authentication number 

21 7. Disseminate RFP to selected user, either: 

22 7.1. Attach to return Email or 

23 7.2. Post the RFP in a repository from which qualified prospective bidders may download the 

24 file. If the repository model is used, provide notice of the posting via email including 

25 any necessary PINs and codes to access the repository 

26 7.3. When a prospective bidder downloads an RFP, issue an encryption key to be used in 

27 submitting proposal 

28 8. The RFP site also includes a page through which prospective bidders can submit questions. 

29 Questions and answers are posted to the site. 

30 . 9. Updates to the schedule and amendments to the RFP are posted to the site 
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1 10. All access to the site is recorded to verify that prospective bidders have received critical 

2 information. Direct contact may be used when it is determined that a bidder had not 

3 accesses the site since critical new information was posted. 

4 11. Bidders prepare their proposal and then upload them to a repository for proposals using 

5 software built into the proposal site. 

6 11.1. Prompt for key 

7 11.2. Encrypt submission 

8 11.3. Upload 

9 1 1 .4. Generate secure hash number to prevent tampering with the submission 

10 11.5. Generate receipt including secure hash number and authentication code 

11 12. After initial proposals are received, the process moves into a phase commonly termed the 

12 "best and final process" in which the proposals are reviewed, the list narrowed, and the 

13 proposals refined. 

14 12.1. Create separate secure environment (i.e. web site with repository) for each 

15 respondent 

16 12.2. Exchange materials through repository (described elsewhere in this filing) 

17 12.3. Records and receipt each access 

18 12.4. Generate key for revised proposal 

19 12.5. Receive proposal using process in 1 1 

20 12.6. Repeat from step 1 1 as many times as necessary 
21 

22 The remainder of the process is completed as a negotiated deal, described below. 

23 Variant B: no pre-qualification: 

24 Proceed as above, beginning with Step 6 and not requiring a key for download of the RFP. 

25 H. Negotiation Deal Engine 

26 An engine for negotiating a deal can be built around the capability of the system to create 

27 a temporary virtual private network through the web. A temporary network is created for the 

28 negotiation. Access to the network is limited to the parties of the negotiation, their advisors and 

29 counsel, and, potentially, arbitrators and regulators. The members of the negotiating environment 

30 have access to the complete set of tools described in this filing including those for 
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1 communications (email, anonymous mail, online chat, threaded dialogs, and audio and video 

2 collaboration), the library of standard contract instruments, the tools for document signature and 

3 authentication, and the document repository. Using these tools in a secure environment they can 

4 negotiate, close, and register a deal. 

5 FIG. 19 shows one possible user interface for selecting participation engines to be made 

6 available to group members. The term "participation engine" refers generally to collaboration 

7 tools that provide features beyond merely communicating among group members. Various 

8 services such as an on-line survey tool, a DELPHI model tool; brain writing tool; and real-time 

9 polling can be provided. 

10 A. Online Survey 

1 1 In online polling or surveying, the person creating the poll uses and automated tool (new 

12 to this application) to build simultaneously an online questionnaire and a database to collect the 

13 results. The user builds the questionnaire by entering a series of questions and an associated 

14 data collection widget for each. The polling tool builds the database and the data entry screen. 

15 The data entry screen consists of two columns. The left column is a series of questions. The 

16 right column is the data entry tool appropriate to the question. Various data entry tools can be 

17 provided to respond to the query, including such things as: 

18 1 . yes / no radio buttons 

19 2. true / false radio buttons 

20 3. slider with scale from 1-5, 1-10, etc. 

21 4 . f ill-in-the-blank text box 

22 5. numeric field 

23 6. multiple check boxes (e.g. strongly disagree, disagree, agree, strongly agree) 

24 Other data entry types may be added. 

25 As each question / data collection widget is added, the polling tool creates the database. 

26 The database includes one record per data collection form. Creating the database structure 

27 simply means adding one new field to each record definition for each question. The type of data 

28 collection widget defines the format of the field, as follows: 

29 1 . yes / no radio buttons: one character field, limited to "y' ' or "n" 

30 2. true / false radio buttons: one character field, limited to "y" or V 
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1 3. slider: real number field, with appropriate range check 

2 4. fill-in-the-blank text box: text box 

3 5. numeric field: real number or integer 

4 6. multiple check boxes: integer field with range check from 1 to number of boxes 

5 Every data entry screen provides a "save" and "cancel" button. Save writes to the database. 

6 Cancel exits the entry screen without saving. 

7 The survey, once composed as described above exists as a web page. This page can be 

8 embedded in web applications. It can be made available on a site available to the entire Internet, 

9 on an Intranet, or in a dynamically created environment. Alternatively, it can be distributed via 

10 e-mail. When the form is completed, the submit button transmits the value entered to the 

1 1 database that is created at the time the form is generated. Access to the database is controlled by 



12 the rules of the database system. It may be limited to the individual who creates the survey 

13 form and database, but it may be accessible other users in the survey developers organization, as 

14 determined by the database administrator. Distribution of the result of the analysis is at the 

15 discretion and control of the individual managing the survey. This manager may be the 

16 individual who creates the survey, but the actual creator may be acting on behalf of the survey 

17 manager. Results may be kept private, posted to the Internet, and intranet, or a collaborative 

18 environment, distributed via e-mail within an organization, or, if the information is available, 

19 sent via e-mail to the participants in the survey. 



20 B, Online Delphi Engine 

21 The online Delphi engine allows real-time collaboration in estimating or predicting an 

22 outcome that can be expressed numerically. For example, the method can be used to develop a 

23 consensus forecast of grain prices. The method has been in used since the 1970s, but has not 

24 previously been adapted to online processes. One possible method is as follows: 

25 1. Establish the session 

26 1.1. Within an online community, the moderator of the session creates the brain writing 

27 session by entering the following information: 

28 1.1.1. Name of moderator 

29 1.1 .2. Title of the session 

30 1.1.3. Description of the session 
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t 1 . 1 .4. Background reading as references or attachments 

2 1.1.5. Start date for the session 

3 L 1 .6. Scheduled end for the session 

4 1.1.7. Access to the session: 

5 1.1.7.1. URL for access 

6 1. 1.7.2. Open to all or invitees only for observation 

7 1.1 .7.3. Open to all or invitees only for participation 

8 1.1.8. Payment information if required 

9 2. Optionally, the session may be advertised on line 

10 3. If the session is private, invitations with logon keys must be distributed via email, actual 

1 1 mail, or download. 

12 4. Optionally, the moderator may run on online applications and qualification process 

13 5. Prior to the start of the session, the moderator must describe precisely the value to be 

14 estimated. The definition must be completely unambiguous. 

15 6. Each participant connects at the start of the session. On connecting, they question is posed 

16 (e.g. "What will be the price of West Texas intermediate oil in December?") 

17 7. Each participant enters a number a brief (1 paragraph maximum) explanation of their 

18 reasoning. 

19 8. When the participant is done entering their estimate, they click "Done". 

20 9. Each participant's estimate and explanation is recorded. 

21 10. Each participant then sees the summary screen. 

22 11. Estimates are arrayed graphically from top to bottom of the screen, from lowest to highest. 

23 The value is stated as is the associated comment, but the source of the comment is not 

24 revealed. 

25 12. Participants can review the estimates and comments, send an anonymous message to the 

26 author or any comment, or amend their answers. 

27 13. The session terminates when the time expires, or when the moderator determines that there it 

28 is no longer appropriate to continue. The operator may determine this is based on declining 

29 participation or, if participation is high, the moderator may extend the deadline. 
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1 14. Participants and observers may access the final display of estimates, again arrayed from top 

2 to bottom, lowest to highest. 

3 C . Brain Writing 

4 Brain writing is a variant of a method for facilitated group discussion termed 

5 brainstorming. The objective of brainstorming is to maintain the focus of the discussion while 

6 encouraging creative input and recognizing the contributions of all members of the group. It 

7 seeks to avoid problems with a few individuals dominating the discussion, with junior staff 

8 deferring to senior staff, and with new ideas being abandoned before than can be developed fully. 

9 Brain storming has been commonly used since the late 1960s. Brain writing is a more intense 

10 method that relies on joint writing rather than discussion. What is presented here is adaptation 

1 1 of that method to an online environment. It is believed to be the first such adaptation. 

12 1. Establish the session 

13 1.1. Within an online community, the moderator of the session creates the brain writing 

14 session by entering the following information: 

15 1.1.1. Name of moderator 

16 1.1.2. Title of the session 

17 1.1.3. Description of the session 

18 1 . 1 .4. Background reading as references or attachments 

19 1.1.5. Start date for the session 

20 1.1.6. Scheduled end for the session 

21 1 . 1 .7. Access to the session: 

22 1.1.7.1. URL for access 

23 1.1 .7.2. Open to all or invitees only for observation 

24 1 . L7.3. Open to all or invitees only for participation 

25 1.1.8. Payment information if required 

26 2. Optionally, the session may be advertised on line 

27 3. If the session is private, invitations with logon keys must be distributed via email, actual 

28 mail, or download. 

29 4. Optionally, the moderator may run on online applications and qualification process 
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1 5. Prior to the- start of the session, the moderator must list some number (typically 5-10) of 

2 questions or hypotheses to be explored, (e.g. " Our company should create a spinoff to 

3 develop and commercialize the new breast cancer vaccine") This may be done by the 

4 moderator alone, in consultation with the participants, or with other outside the session. 

5 6. Each question or hypothesis becomes a "Card". 

6 7. Participants may enter the session any time after the start. A password may be required if the 

7 session is not open. 

8 8. On entry into the system, a user if given a card at random. The card consists of the initial 

9 question or hypothesis plus all comments entered on the card by other participants. 

10 9. After reviewing the card, the participant may add his or her own comments to the bottom. 

1 1 After entering comments, the participant clicks "Done" to return the card to the pile. 

12 10. When a participant returns a card to the pile, they received another card, chosen at random 

13 (preferably) or selected by the user. This process continues until the opt to exit. They may 

14 reenter at any time up to the conclusion of the session. 

15 11. When a card is returned to the pile, it is become available for assignment to the next 

16 participant. The card includes the additions of the most recent participant. 

17 12. A participant may opt to return the card without addition if he or she has nothing to add. 

18 13. Participants may create new cards when new ideas come to mind. These are treated in 

19 exactly the same way as original cards. 

20 14. Observers may view any card but may not add to them. 

21 15. The moderator may limit participation to a set number at any time so that there is a sufficient 

22 number of cards to keep the participants fully occupied. 

23 16. The session terminates when the time expires, or when the moderator determines that there it 

24 is no longer appropriate to continue. The operator can determine this based on declining 

25 participation or, if participation is high, the moderator may extend the deadline. 

26 17. The raw cards are distributed at the conclusion to all participants. The moderator or another 

27 individual is charged preparing a summary and arranging follow-up. 

28 FIG. 22 shows one possible scheme for storing brain card writing data elements. In 

29 accordance with one embodiment, each brain writing card comprises a data structure including 

30 the following elements: 
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1 1. Brain writing session number: Serially assigned number to differentiate brainwriting 

2 sessions. A session is the set of all cards pertaining to a particular topic. 

3 2. Card number: A Serially assigned sequence number 

4 3. Initial Comment : The question or comment used to initiate the discussion (e.g. 

5 "SAIC should purchase a company that produces Internet server software" 

6 4. Date and time card started 

7 5. Date and time card closed 

8 6. Comments: A collection (i.e. a set of unlimited length) containing the comments 

9 added by participants in the brainwriting session. 

10 7. Date of additional comment: Date and time that each additional comment was added. 

1 1 8 - Commenter: Name or user ID of the person adding each additional comment. Ideally, 

12 brainwriting should be anonymous to encourage open dialog. Accordingly, this field 

13 ma y be omitted from an implementation. Some organizations, however, may wish to 

14 track this information without making it visible to users, or in some cases to attribute 

15 comments. 

16 When the user has finished defining the group and specifying its functions, environment 

17 generator 1201a (FIG. 12) creates an environment accessible to the group members and including 

18 the functions specified during the environment definition process. As shown in FIG. 20A, for 

19 example, a web page can be created for the newly created environment, including those functions 

20 that were selected by the user that created the group. All group members are notified of the 

21 existence and location of the environment, and each group member can use the functions 

22 provided in the environment to collaborate on a project or conduct business. 

23 FIG. 20B shows what an environment might look like to a group member after entering 

24 the environment. As shown in FIG. 20B, for example, a news banner announces the latest news 

25 for the group. Additionally, specific communication tools, research tools, transaction engines, 

26 and participation engines are made available to group members, which can be executed by 

27 appropriate mouse clicks in accordance with the inventive principles. According to various 

28 inventive principles, each tool shown on the web page is accessible through a hyperlink to a web- 

29 based program that performs predefined functions as set forth above. For example, clicking on 

30 "online catalog" would link the group member to a web page that implements an online ordering 
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1 engine as described previously. Users can navigate through the various tools using conventional 

2 web browser features (i.e., forward, backward, etc.). It may be desirable to implement some or all 

3 of such software using server-side scripting or other similar means consistent with the system 

4 configuration of FIG. 12. 

5 FIG. 21 shows how environment generator 1201a can create multiple environments 

6 including virtual private facilities, which can be implemented through web pages that contain 

7 hyperlinks to functions available to members of each group or environment. An environment 

8 definition software component 2106 implements steps 1101 through 1 103 of FIG. 1 1 in order to 

9 create one or more environments 2107. (In one embodiment, each group can also be provided 

10 with a copy of an environment generator 2106 in order to create sub-groups that draw on the 

1 1 applications and directory structure created for the group). As a user identifies group members 

12 and selects functions to be provided for the environment in which the group will collaborate, 

13 environment definition component 2106 stores information relating to the selected members and 

14 functions in databases. Each environment can include a web page (not shown in FIG. 21) and 

15 directories, tools and other applications specific for each created group. 

16 Based on user selections of the type illustrated in FIGS. 13 through 19, environment 

17 generator 2106 creates an environment 2107 containing one or more web pages with links to the 

18 selected tools. Environment generator 2106 retrieves information from various information 

19 sources including a directory of communication tools 2101 (e.g., including descriptions of tools 

20 and URL/IP addresses of web applications to set up each communication tool); directory of 

21 transaction engines 2102 (e.g., including descriptions of transaction engines and the URL/IP 

22 addresses of web-based applications to set up each transaction engine); directory of research tools 

23 2103 (similar to above); list of global data objects 2104 (e.g., a dictionary of data elements from 

24 which the directory of each group can be composed); and a directory of applications 2105 (e.g., a 

25 description of available applications and URL/LP addresses of pages to set up access to 

26 applications). 
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1 WE CLAIM: 

2 1. A method of negotiating a deal over a network of computers, the network including at 

3 least one or more computers connected to the Internet, the method comprising the steps of: 

4 (1) posting, on an electronic list that can be viewed over the Internet, information 

5 regarding one or more offers to form a contract; 

6 (2) posting on the electronic list one or more responses to the one or more offers; 

7 (3) researching the one or more responses to determine whether they satisfy one or more 

8 contract criteria; 

9 (4) negotiating over the network between at least two parties to accept or modify one or 

10 more of the responses; and 

1 1 (5) electronically signing a document to consummate the contract. 

12 2. The method of claim 1, wherein step (1) comprises the step of displaying offers and 

13 responses in a parent-daughter spatial relationship on a computer display. 

14 3. The method of claim 1, further comprising the step of sorting the one or more offers 

15 and one or more responses according to a user-selected sort order. 

16 4. The method of claim 1, wherein steps (1) and (2) are done anonymously, such that 

17 each party to the contract cannot determine the identity of the other party to the contract. 

18 5. The method of claim 4, further comprising the step of simultaneous revealing the 

19 identity of each party prior to step (5). 

20 6. The method of claim 4, wherein steps (1) and (4) comprise the step of sharing a single 

21 anonymous e-mail alias among a plurality of users. 

22 7. The method of claim 1, further comprising the steps of: 

23 (6) registering keywords with an electronic agent that monitors the one or more offers and 

24 providing an e-mail address to be notified upon a keyword match; and 

25 (7) in response to the electronic agent detecting the keyword match, transmitting a 

26 message to the e-mail address provided in step (6). 

27 8. The method of claim 1, wherein step (2) comprises the step of clicking on a hyperlink 

28 linking the information posted in step (1) to a reply card. 

29 9. The method of claim 7, wherein step (2) comprises the step of requiring the 

30 submission of certain information before the reply card will be accepted. 
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1 10. The method of claim 1, wherein steps (3) and (4) are performed a plurality of times 

2 for a single contract, such that modifications are made to the one or more responses. 

3 11. The method of claim 1, further comprising the step of electronically registering a 

4 plurality of entities that have signatory authority and correlating the registered entities with one 

5 or more documents to which signatures can be affixed. 

6 12. A method of displaying information on a computer display, comprising the steps of: 

7 (1) displaying a first plurality of graphical objects each having a shape of a file folder 

8 comprising a folder face and a labeled tab, wherein the first plurality of graphical objects are 

9 stacked in a cascading arrangement; and 

10 (2) in response to user activation of a "flip" tab, changing the graphical objects displayed 

1 1 in step ( 1) to show a second plurality of graphical objects each having a shape of a file folder 

12 comprising a folder face and a labeled tab, 

13 wherein each of the first and second plurality of graphical objects can be brought to a 

14 foreground position in front of other graphical objects by clicking on a corresponding labeled tab. 

15 13. The method of claim 12, wherein each of the first and second plurality of graphical 

16 objects has associated therewith one or more functions displayed on the folder face thereof, 

17 wherein user can activate the one or more functions by clicking thereon. 

18 14. A method of creating a user-defined networked environment across a plurality of 

19 computers without requiring system administrator-level privileges, comprising the steps of: 

20 (1) creating a group by providing a group identifier, a group description, and by 

21 specifying a plurality of group members entitled to use the user-defined networked environment; 

22 (2) selecting a plurality of web-based communication, collaboration, and transaction tools 

23 from a list of available tools, wherein the selected tools are to be made available to the plurality 

24 of group members specified in claim 1; and 

25 (3) through the use of computer software, automatically creating the user-defined 

26 networked environment by creating a web page accessible to the plurality of group members 

27 selected in step (1), wherein the web page provides access to the plurality of tools selected in step 

28 (2). 

29 15. The method of claim 14, wherein step (1) comprises the step of inviting a plurality of 

30 individuals to join the group by transmitting an invitation to prospective group members. 
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1 16. The method of claim 14, wherein step (1) comprises the step of advertising an 

2 invitation to join the group by posting an advertisement for prospective group members, wherein 

3 at least some of the prospective group members are unknown to the user creating the networked 

4 environment. 

5 17. The method of claim 14, further comprising the step of screening prospective 

6 members that respond to the advertisement in order to determine whether they should be added to 

7 the group. 

8 18. The method of claim 14, further comprising the steps of electronically collaborating 

9 among group members using the user-defined networked environment. 

10 19. The method of claim 14, further comprising the step of destroying the user-defined 

1 1 networked environment when it is no longer needed. 

12 20. The method of claim 14, wherein step (2) comprises the step of selecting a 

13 transaction engine that implements an auction to members of the group. 

14 21. The method of claim 14, wherein step (2) comprises the step of selecting a 

15 transaction engine that implements an on-line electronic survey comprising survey questions that 

16 are to be answered electronically by survey participants. 

17 22. The method of claim 14, wherein step (2) comprises the step of selecting a 

18 transaction engine that implements a bid-and-proposal tool that permits group members to 

19 electronically submit bids on one or more proposals. 

20 23. The method of claim 14, wherein step (2) comprises the step of selecting an online 

21 ordering engine that permits group members to electronically order goods or services in the user- 

22 defined networked environment. 

23 24. The method of claim 14, wherein step (2) comprises the step of selecting an 

24 Electronic Data Interchange (EDI) compatible interface that executes electronic commercial 

25 transactions between two or more group members. 

26 25. The method of claim 14, wherein step (2) comprises the step of a selecting an 

27 electronic brain-writing tool that permits participants to brainstorm using electronic idea cards. 

28 <26. A system for implementing a user-defined networked environment that can be 

29 created without the need for system administrator-level privileges, comprising: 

30 a plurality of networked computers that communicate using Internet Protocol; 
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1 a plurality of web browsers executing on the plurality of networked computers; 

2 a database that stores information concerning the user-defined networked environment; 

3 and 

4 a computer program executing on one or more of the plurality of networked computers, 

5 wherein the computer program performs the steps of: 

6 ( 1 ) permitting a user to create a group comprising a plurality of group members; 

7 (2) permitting the user to select a plurality of web-based communication, collaboration, 

8 and transaction tools from a list of available tools, wherein the selected tools are to be made 

9 available to the plurality of group members; and 

10 (3) automatically generating a web page accessible to the plurality of group members, 

1 1 wherein the web page provides access to the plurality of tools selected in step (2) to the plurality 

12 of group members. 
13 
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1 

2 ABSTRACT 

3 A collaborative system and method allows members Qf a group to collaborate on a project 

4 such as a bid or proposal. According to a first embodiment, a complex instrument trading engine 

5 (CITE) facilities negotiation between two or more parties. A set of tools and techniques are 

6 provided in order to facilitate negotiation and execution of complex instruments such as contracts 

7 between corporations and governments. According to a second embodiment, referred to as a 

8 dynamic collaborative environment, a user can define a group and a virtual private network 

9 environment including user-selected tools that facilitate communication, research, analysis, and 

10 electronic transactions within the group. The environment can be destroyed easily when it is no 

1 1 longer needed. Multiple environments can co-exist on the same physical network of computers. 



80 





Analysis 



— 5 

Negotiate 




Fig. 1A 




communication 



Fig. 1B 



Number 
123 
23< 



314 



236 



239 
240 
243 



313 



Date 

7/10/87 

7/12/87 

7/12/87 

7/10/88 

8/12/87 

9/01/87 



Market 

Steel 

Alum. 

Gold 
Flood 



Action 

Buy 

Sell 



Action 
Action 
Action 



Title 
Title 
Title 
Title 
Title 
Title 
Title 



312 



Fig. 2 



# 

Date 
Title 
Market 
Action 

Description 




Attachment 1 
Attachment 2- 



304 



Attachment 3 



302 



Instructions for responding 



Reply 



303 



Fig. 3 



Reply to Listing 145: Request for Bid on School Construction 

[_ v __ Name of Company 

| Address 

| 1111 111 D&B Number 

References for Construction Work in Fairfax County 

I ' 

L 

Do you qualify as a* 

C Small Business 

€ Minority owned business 

r Woman owned business 



Fig. 4 




Fig. 5 




Fig. 6 



Trade Number Date Created ; Trade Title 


357 Sep 22 1998 >Jmimnrnmmn^ 


356 


Sep 22 1998 * 


World Trade Center 


353 


Sep 22 1998 


Florida "Windstorm Coverage 


352 


Sep 22 1998_ 


WW 


342 


Sep 1 1998 ; 


Bigger deal 


341 


Sep 1 1998 [big deal 


330 


Aug 18 1998 lAnother trade 


297 


Jim 23 1998^|5gss^_ 


295 (Jun23 1998 |lkjdalskjd 


293 


Jun23 1998 t 


Test again 


292 


Jun 23 1 998 [|Test of compiled tm 


6 


Feb 11 1998 j 


Get in shape 


5 


Feb 10 1998 ! 


Big Deal 


4 


Feb 8 1998 ! 


Master Contract 



? Sc&nceApplfcatfom 
Copyright SAIC, 1998. All rights reserved. 



Fig. 7 




Fig. 8A 



Specify Title, Rate Summary, Deal Summary, Slip Sheet, Exhibits, and Authorizing Parties 



Tide: I 
Rate Summary | 

Deal Summary. 

Slip Sheet. 

Add Exhibit 
Description 1 
Add Exhibit 
Description: 



*am*m 



I 



Specify Parties who will Authorize the Deal 

|j| Authorizing Parties: 



Company 



Names 



Company Alpha : M 
Company Beta 3 
Company Gamma *J 



John Q. Client 
Craig Miller 



mm 



None. None 



Fig. 8B 




Fig. 10 



CO 
CNJ 
O 



.Q 

CM 
O 



Q. 

§ 2 o) 
2> ? o E 

to J- 10 > 
CD © CD (0 

,^ 2 Q 0_ 



o 

CNJ 

o 




>, CD 
S= Q--Q 

= O E 

CD 2 CD 

2(5E 



Q. 

13 
O 



(/) LL < O 



C 
0 

E 

CO > 
0 c 
Q LU 




O 



00 

o 



CM 
O 



FIG. 13 A 



a| CREATE HEW ENVIRONMENT - Microsoft Internet Explore! 



lililiM 



Refresh 



Home 



: Search Favorites H 



Mai! 



Print 



CAWINDOWSSDESKTO Pfigure 1 3[a).htm 



CREATE NEW ENVIRONMENT 



User Name: 
Password: 



1 Done 



JoeUser 



SloppyJoe 



FIG. 13B 



41 CREATE HEW ENVIRONMENT - Micro soft internet Explo rer 



WB&B Edit 1 yVie^^-J^^ ; : : j 



mmmm^mmm a 

jlidll i; :i:i,;iiadig|ii I'-aa^i- i^&ftesh Home 



m 



j^H|)gl HAUSERSWR!GHTSWORK\0479\75932\Rgure 13[b).htm 



CREATE NEW ENVIRONMENT 

Name of Group: 



Joe's Homework 



Description: 



Joint project for Ms. Johnson's 8th period social 
studies class to examine trends in drug use in 
high schools across the country and in North 
High School. 



FIG. 13C 



3 CREATE NEW ENVIRONMENT - Microsoft Internet Explorer 



mm 



||;l|ii||||ii||ij t es lods Help 



: Search Fa#rites ;: Histoid 1 



Address #] HAU5ERS\WRIGHT\WORK\0479\75982\R9ure13[c).htm 



i Links 



IDENTIFY GROUPMEMBERS 

Name of Group: Joe's Homework 

■■■■SiilsSii 

musmim 



in 



ffif 



IS 
if? 

1 

If 



FIG. 14A 



H CREATE NEW ENVIRONMENT - Microsoft Internet Explorer 



For»;*d Stop 



$1 



Refresh Home 



Search Favorites HisLrj" 



W\ H:\USERS\WRIGHT\WORK\0479\75982\Figure 14[a).htm 



SELECT GROUP MEMBERS 
Name of Group: Joe's Homework 

1 . Enter addresses of new members, click "add" after each 



2. Click on addresses of people already in the community. 



craig.miller@cpmx.saic.com 

peter.parker@spiderman.org 

lois.lane@superman.org 

nino.scaparelli@bignet.it 

joe.student@northhigh.va.gov 

Click here when done: 



one 



FIG. 14B 



H CREATE NEW ENVIRONMENT - M icrosoft Interne* E xplorer 



;[^|S|||g| H.\USERS\WRIGHT\W0RtC\Q479\75982\Figure Hjb].hlm Jlf fel^^iJ.frB 



INVITE GROUP MEMBERS 



INVITE GROUP MEMBERS 



1. Enter address:! bobObiaisp.com 



2. Expiration date for invitation:! .10/13/1999 

3. Invitation Message: 



You are invited to join our group project on drug use in high schools. I think 
we have a good team. 



4. Click to send invitation & invite next member: 

5. Click when done: 



Done 



I 



9, 
$ 

IS 



FIG. 14C 



a§ CREATE HEW ENVIRONMENT - Microsoft Internet Explorer 




MM 


Illf 


liiBsieiiwaffiass 


1 J> 

I 




^^^^P^^^I'^ ■ 



ADVERTISE FORGROUP MEMBERS 
INVITE GROUP MEMBERS 
IP/URL address for banner ad: 

| bob(3!biaisD.com 
Message: 



You are invited to join our group project on drug 
use in high schools. I think we have a good team. 



Expiration date for invitation: 
Click for qualifications: 





FIG. 15 



<3 H:\USERS\WRIGHT\WQRK\0479\75982VFigure 15.htm - 


Microsoft Internet Explorer 






S Ea*. "c-=.v-.r-c Stop Refresh Home 


: ;» 
■ ■ ■ :■ 




HT\WORK\Q479\75982\Figure 15.htm * 






SAIC is looking for minority contractors interested in forming a long-term 
relationship. Our company bids information technology jobs for 
government and private clients in all part of the country. 



Click here for more information and to submit qualifications!; 



TODAY'S NEWS 



SM^MiiHSISIlIi 



FIG. 16 



<5 SELECT COMMUNICATIONS TOOLS - Microsoft Internet Explorer i 




i 5 le £* Vie. Io* m 








WM 

■■■■ mmm 


1 '-Sift |jl 1 ftr^J]' :gfj$^^ 


Search Favorites ■ History 






H:\USERS\WRIGHT\WORK\0479\75982\Rgure 1G.htm 3^M^°" : I 


jinks » 



SELECT COMMUNICATIONS TOOLS 



Bulletin Board / Post and Browse 

Advertisement 

White Pages 

Yellow Pages 

Document Security 

Anonymous E-Mail 

Threaded Dialogs 

Group Newsletter 

Audio Conference 

Video Conference 



Other Links 



Title 



URL 



FIG. 17 



1 HT\WORK\0479\75982\Figure 17.P 



SELECT RESEARCH TOOLS 

Mortgage calculator 
Dun and Bradstreet 
A.M. Best 
Washington Post 
Valueline 

Risk Management Solutions 
Applied Insurance Research 
National Hurricane Center 
CCH 

Lexis/Nexis 

Other Links 



Title 



URL 




eal intranet 



FIG. 18 



j Die Edit View Favorites Tools Help 



Search Jay^es^l^y J 







■ Mail ' 






j|jpPl|glC:VWIND0WS\DESKTOP^Figure18.htm 



SELECT TRANSACTION ENGINES 

Online Catalog(s) f- will display a screen to enter URLs for catalogs 

EDI Engine(s) 4- will display a selection of engines based on ANSI, EDIFACT, or proprietary standards 

English Auction 
Dutch Auction 
Reverse Auction 
Japanese Auction 
Request for Quote 
Tender an offer 
Bid and Proposal 
Negotiated Deal 
Syndicated Deal 



Other Links 
Title 



URL 



^ _ 



_ 



FIG. 19 




HT\WORK\0479\75982\Figuie 



19.htm ^jl^l^l 



SELECT PARTICIPATION ENGINES 

Online Survey 
Delphi 

Brain Writing 
Real Time Polling 



Other Links 
Title 



URL 



tiii 

; 

I 



FIG. 20A 



<5 SELECT COMMUNICATIONS TOOLS - Microsoft Internet Explorer 



TsTxl 



s 



WELCOME TO JOE'S RESEARCH PROJECT! 



log in: 



User Name: 
Password: 

Send a message to the group 



FIG. 20B 



£j SELECT COMMUNICATIONS TOOLS - Microsoft Internet Explorer 



IlBack " ' Stop Refresh Home \ 



» 



iPS$y#] TWORK\0479\75982\Figure 20(b].htrnj|| "S^Go 



WELCOME TO JOES RESEARCH PROJECT! 



Latest News: 

Online team meeting at 7:30 tonight. Everyone bring drafts of their sections for review 
online. See you there. 

Joe 



Bulletin Board , 
Yellow Pages 
Newsletter 

BC News 
Washington Post 

Online Catalog 
Bid and Proposal 

Online Survey 



Communication tools 

Research Tools 
Transaction Engines 
Participation Engines 



FIG. 22 



Brain writing session number 

Card number 

Initial comment 

Date and time card started 

Date and time card closed 

\ Brain writing session number 

X. y Card number 

Date of additional comment 

Commenter 

Comment 



Attorney Docket No 00479.83892 

JOINT DECLARATION AND POWER OF ATTORNEY 
FOR PATENT APPLICATION 

As the below named inventors, we hereby declare that: 

Our residences, post office addresses and citizenships are as stated below next to our names: 

We believe we are the original, first and joint inventors of the subject matter which is claimed and for which a 
patent is sought on the invention entitled: 

USER-DEFINED DYNAMIC COLLABORATIVE ENVIRONMENTS 

the specification of which 

58k is attached hereto. 

r was filed on as Application Serial Number and was amended on (if 

applicable). 

We hereby state that we have reviewed and understand the contents of the above identified specification, 
including the claims, as amended by any amendment referred to above. 

We acknowledge the duty to disclose information which is material to patentability in accordance with Title 37, 
Code of Federal Regulations, 31.56. 

0 Prior Foreign Application(s) 

%Je hereby claim foreign priority benefits under Title 35, United States Code, 3l19(a)-(d) or 365(b) of any foreign 
"^pplication(s) for patent or inventor's certificate, or 365(a) of any PCT international application which designated at least 
^dne country other than the United States of America, listed below and have also identified below any foreign 
Jfppiication(s) for patent or inventor's certificate having a filing date before that of the application on which priority is 
Mdlaimed: 



Country 


Application Number 


Date of Filing 
{day, month, 
year) 


Date of Issue 
{day, month, 
year) 


Priority Claimed 
Under 35 U.S.C. 

3119 


Certified Coov 
Attached 










Yes / No 


Yes / No 



jNe hereby claim the benefit under 35 U.S.C. 1 19(e) of any United States provisional applicationfs) listed below: 



Application Number(s) 


Filing Date 
(MM/DD/YYYY) 


Additional provisional application numbers 
are listed on a supplemental priority data 
sheet PTO/SB/02B attached hereto. 


60/101,431 


09/22/98 



Prior United States Application^) 

We hereby claim the benefit under Title 35, United States Code, ^120 of any United States application(s) listed 
below and, insofar as the subject matter of each of the claims of this application is not disclosed in the prior United 
States application in the manner provided by the first paragraph of Title 35, United States Code, a1 1 2, We acknowledge 
the duty to disclose material information as defined in Title 37, Code of Federal Regulations, ^1.56 which occurred 
between the filing date of the prior application and the national or PCT international filing date of this application: 



Application Serial 
Number 


Date of Filing 
(Day, Month, Year) 


Status X Patented, 
Pending, Abandoned 









Page 1 of 4 



Power of Attorney 



And we hereby appoint, both jointly and severally, as our attorneys with full power of substitution and revocation, 
to prosecute this application and transact all business in the U.S. Patent and Trademark Office connected herewith as 
well as before any office or agency of a foreign country or any international organization in connection with any foreign 
counterpart application claiming priority to this application, including the power to appoint agents and local 
representatives in connection with such foreign applications, the following attorneys of Banner & Witcoff, their 
registration numbers being listed after their names: 

Robert Altherr, Reg. No. 31,810, Donald W. Banner, Reg. No. 17,037; Edward F. McKie, Jr., Reg. No. 17,335; 
William W. Beckett, Reg. No. 18,262; Dale H. Hoscheit, Reg. No. 19,090; Joseph M. Potenza, Reg. No. 28,175; James 
A. Niegowski, Reg. No. 28,331 ; Joseph M. Skerpon, Reg. No. 29,864; Thomas L. Peterson, Reg. No. 30,969; Nina L. 
Medlock, Reg. No. 29,673; William J. Fisher, Reg. No. 32,1 33; Thomas H. Jackson, Reg. No. 29,808; Kevin A. Wolff, 
Reg. No. 42,233; Franklin D. Wolffe, Reg. No. 1 9,724; Susan A. Wolffe, Reg. No. 33,568, and Bradley C. Wright, Reg. 
No. 38,061 



All correspondence and telephone communications should be addressed to: 

Banner & Witcoff, Ltd. 

Eleventh Floor 
1001 G Street, N.W. 
Washington, D.C. 20001-4597 
Tel. No. (202) 508-9100 



?0 We hereby declare that all statements made herein of our own knowledge are true and that all statements made on 
•information and belief are believed to be true; and further that these statements were made with the knowledge that 
^willful false statements and the like so made are punishable by fine or imprisonment, or both, under 18 U.S.C. 1001 and 
,iiat such willful false statements may jeopardize the validity of the application or any patent issuing thereon. 

Date Iff/*! 



-^Signature 

fflull Name of 

ifloint Inventor Miller Craig 

nj Family Name First Given Name Second Given Name 

Residence 5687 Rayburn Avenue, Alexandria, VA 2231 1 

Citizenship U.S. 

Post Office 

Address c/o Science Applications International Corporation, 10260 Campus Point Drive, San Diego, CA 92121 

Signature (lA/l *!' 7*7\ Date_ 

Full Name oW J f 

Joint Inventor Mangis Jeffrey K. 

Family Name First Given Name Second Given Name 

Residence 212 Park Terrace Court SE #78, Vienna, VA 22180 

Citizenship U.S. 

Post Office 

Address c/o Science Applications International Corporation, 10260 Campus Point Drive, San Diego, CA 92121 
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( £^t^4\ . /U^lc^ ' Date 



Signature 

Full Name of 

Joint Inventor Lester . Harold D. 

Family Name First Given Name Second Given Name 

Residence 5378 Beverly Mill Road, Broadview, VA 20137 

Citizenship U.S. „ 



Post Office 

Address c/o Science Applications International Corporation, 10260 Campus Point Drive, San Diego, CA 92121 



Signature_ _ Date_ 

Full Name of 



Joint Inventor Nicholas John M. 

Family Name First Given Name Second Given Name 



Residence 3123 Barbara Lane, Fairfax, VA 22031 
Citizenship U.S. 



rgost Office 

^Address c/o Science Applications International Corporation, 10260 Campus Point Drive, San Diego, CA 92121 





Signature 0 siL J^CT 'Z/ ^ Date £tf4^ftff 

Hull Name of ~ * 7 / 
IJIoint Inventor Wallo Andrew 

y Family Name First Given Name Second Given Name 
Residence 1605 North Craig Street, Sterling, VA 20104 



Citizenship U.S. 



;Post Office 

^Address c/o Science Applications International Corporation, 10260 Campus Point Drive, San Diego, CA 92121 

Signature ^ A^U^ Date 

Full Nameof 

Joint Inventor Kress Thomas FV, 

Family Name First Given Name Second Given Name 

Residence 3639 Autumn Glen Circle, Burtonsville, MP 20866 



Citizenship U.S. 



Post Office 

Address c/o Science Applications International Corporation, 10260 Campus Point Drive, San Diego, CA 92121 
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UuL i Date I /*> fa 



Signature 

Full Name of 

Joint Inventor Cheal ^ Linda 



Family Name First Given Name Second Given Name 
Residence 6812 Jefferson Avenue, Fails Church, VA 22042 



Citizenship U.S. 



Post Office 

Address c/o Science Applications International Corporation, 10260 Campus Point Drive, San Diego, CA 92121 




Signature 
Full Name of 

Joint lnventor J / / Weatherbee 

Family Name First Given Name Second Given Name 

Residence 3038 Covington Street, Fairfax, VA 22031 

Citizenship U.S. 

d *ost Office 

Address c/o Science Applications International Corporation, 10260 Campus Point Drive, San Diego, CA 92121 

Signature ^^y^i^n ^ cE^/fr^>ri^ Date f - - 

flull Name of 

Ifloint Inventor Davies Linda M. 

hj Family Name First Given Name Second Given Name 

Residence 10109 Sorrel Avenue, Potomac, MP 20854 

Citizenship U.S. 

r#ost Office 

Address c/o Science Applications International Corporation, 10260 Campus Point Drive, San Diego, CA 92121 



LAW OFFICES 

Banner & Witcoff, Ltd. 

1001 g street, n.w. 
washington, d.c. 20001-4597 

(202) 508-9100 
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